Postman卡在“Sending request”是连接阶段失败，需优先检查Connection timeout（建议设30000ms）、关闭系统代理或绕过localhost，并用ping、nc等验证本地服务可达性，而非盲目调Response timeout。
Postman 卡在 “Sending request” 状态，基本可以确定是连接阶段卡死，不是响应慢，而是根本没发出去或连不上——这时候调 Response timeout 没用，得先解决 Connection timeout 和代理干扰。
Connection timeout 设为 0 是否可行
可以设为 0，Postman 会无限等待连接建立，但不推荐。因为 Connection timeout 为 0 时，一旦目标地址 DNS 解析失败、端口被防火墙拦截、或服务根本没监听，Postman 就会一直挂起，无法自动失败报错，你得手动关掉重试。实际调试中，设成 30000（30 秒）更合理：既覆盖本地开发环境常见延迟（如 Docker 启动慢、Spring Boot 热加载未就绪），又能在真出问题时及时中断。
为什么关闭系统代理能解决 Sending 卡住
Postman 默认启用系统代理（Use the system proxy），而很多开发机的系统代理其实是空配置或指向一个已失效的 HTTP 代理地址（比如公司旧内网代理）。这时 Postman 会尝试把 localhost 或 127.0.0.1 的请求也转发过去，结果就是连接卡在“试图连代理”，而不是连目标服务。常见现象包括：
- 请求
http://localhost:8080/api/user卡住，但curl http://localhost:8080/api/user正常返回 - Postman 日志里出现
ERR_PROXY_CONNECTION_FAILED或类似网络层错误 - 仅对本地地址卡住，调线上 API 却正常
解决方法很简单：进 Settings → General → Proxies，取消勾选 Use the system proxy；或者保留它，但在 Bypass List 里明确加上 localhost,127.0.0.1,::1。
setTimeout 在 Tests 里根本不能控制发送时机
很多人看到文档里写 setTimeout 就以为能“让下一个请求等 5 秒再发”，这是误解。Postman 的 Test script 是在当前请求**收到响应后**才执行的，setTimeout 只会影响后续脚本日志或变量设置，完全不阻塞下一条请求的触发。你写：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
pm.test("delay", function () {
setTimeout(() => { pm.environment.set("waited", "yes"); }, 5000);
});
结果是：当前请求一返回，Postman 立刻发下一条，不管上面那个 setTimeout 还剩 4999ms 没执行完。真要控制集合内请求节奏，得用 Collection Runner 的 Delay between requests 参数，或者用 pm.sendRequest 手动串行发起——后者才能真正实现“等上一个完成、再等 N 毫秒、再发下一个”。
卡在 Sending 时别急着改超时，先做三件事
绝大多数 “Sending request” 卡住，和超时设置无关，而是底层连接失败。优先验证这三项：
- 用
ping localhost或ping 127.0.0.1确认本机网络栈可用 - 用
nc -zv localhost 8080（Linux/macOS）或Test-NetConnection localhost -Port 8080（PowerShell）确认目标端口确实在监听 - 关掉所有杀毒软件/防火墙临时测试，特别是 Windows Defender 的“网络保护”功能，它有时会静默拦截 Postman 的 outbound 连接
这些做完再调 Postman 设置，否则只是在掩盖真实问题。尤其注意：Postman 桌面版基于 Electron，某些企业策略会禁止其访问 loopback 地址，这种限制连代理绕过都无效，只能换浏览器版或 curl 验证。
