Postman上传请求卡在“Sending…”时，大概率是请求未发出或被中间层静默拦截：需用Wireshark抓包验证是否发出SYN包；若无，则检查SSL证书验证、代理配置或TLS版本兼容性；若有SYN无ACK，说明网络路径不通；同时禁用手动填写Content-Type boundary、确保文件路径有效、避免网页版限制。
Postman上传请求卡在“Sending…”或长时间无响应，大概率不是后端挂了，而是请求根本没发出去，或者发出去后被中间层（TLS、代理、防火墙）静默拦截了。
Postman卡在“Sending…”时，先确认是否真发出了请求
很多人误以为“点击 Send 就等于发包”，但 Postman 在某些配置下会卡在预处理阶段，压根不走网络。最直接的验证方式是抓包：
- 用
Wireshark或Fiddler监听localhost或目标域名，看是否有 TCP SYN 包发出 - 如果没有，说明卡在 Postman 本地：检查是否启用了「SSL certificate verification」且服务端证书异常（如自签名、过期），Postman 会阻塞而不报错
- 如果有 SYN 但无后续 ACK，说明网络路径不通，可能是代理配置错误或公司防火墙策略拦截了 multipart 请求
multipart 请求卡住的典型协议级原因
文件上传比普通 JSON 请求更脆弱，因为整个请求体是二进制流 + 多段 boundary 分隔符，任何环节出问题都会导致服务端解析器卡死或超时。常见触发点：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Content-Type被手动填写为multipart/form-data; boundary=xxx—— 这是大忌。Postman 的 form-data 模式会自动计算并注入 boundary，手动填会导致两端 mismatch，后端收不到完整 part - 选中了 file 类型字段，但实际文件路径无效：Postman 提示
The file above is not in your working directory时，它不会报错，而是静默跳过该字段，导致后端收不到file参数而一直等待 - 文件过大且后端未调大超时时间：Spring Boot 默认
spring.servlet.session.timeout=30m，但 multipart 解析超时由spring.servlet.multipart.resolve-lazy和容器线程池共同决定，大文件上传可能卡在解析阶段
代理和 TLS 版本不兼容导致“假死”
Postman 桌面版默认使用较新的 TLS 版本（如 TLS 1.3），而某些老旧网关、内网负载均衡器或测试环境 Nginx 只支持 TLS 1.2。此时请求既不失败也不响应，表现为无限等待。
- 快速验证：在 Postman Settings → Proxy 中启用「SSL certificate verification」关闭，同时勾选「Use system proxy」，再试一次
- 若仍卡住，尝试用浏览器打开同一 URL，F12 网络面板复制 cURL 命令 → Postman Import → Send。能通说明是 Postman 默认 TLS/HTTP2 行为与服务端不兼容
- 终极手段：Postman 不支持降级 TLS 版本，此时需改用
curl -k --http1.1手动构造请求验证
真正棘手的是那些没有错误日志、没有超时提示、连 TCP 层都看不到数据包的情况——这往往意味着 Postman 的 working directory 权限异常、沙箱策略阻止了文件读取，或者你正在用网页版 Postman（受限于浏览器同源策略和 Blob API 限制），这些细节比接口逻辑本身更容易被忽略。
