删掉手动设置的Content-Length即可解决请求卡在“Sending request”的问题,因为Postman会自动计算并设置正确的UTF-8字节数,手动填写易导致大小不匹配而超时或解析失败。

Postman里手动填了Content-Length但请求卡在“Sending request”
直接删掉 Content-Length 请求头就行。Postman 本身会自动计算并设置正确的值,你手动加反而容易出错——只要填的数字和实际 body 字节数不一致,服务器就会一直等满那个字节数,最终超时或无响应。
常见触发场景:
- 从 curl 命令导入请求后,改了
body却忘了同步更新Content-Length - 用
x-www-form-urlencoded或raw JSON改了字段值,但 header 里的Content-Length还是旧的 - 复制别人导出的请求,里面带了硬编码的
Content-Length头
验证方法:打开 Postman 的 Headers 标签页,搜 Content-Length,如果存在且不是由 Postman 自动生成(即不是灰色、不可编辑状态),基本就是它的问题。
为什么删掉 Content-Length 反而能通
因为 Postman 在发送前会主动做两件事:
- 对当前选中的 body 类型(
raw、form-data、x-www-form-urlencoded)做真实字节计算(不是字符数,是 UTF-8 编码后的字节数) - 把算出来的值自动塞进
Content-Length头,并设为只读(灰色)
手动设置等于绕过了这个机制。一旦你填的值偏大,服务器收不到足量数据就挂起;偏小,可能截断 body 导致后端解析失败(比如 JSON 少个 })。
注意:form-data 类型下,Postman 不会自动加 Content-Length(因为 multipart body 长度动态变化),所以这里手动加反而更危险。
Postman Mac版是一款专为macOS设计的API开发与测试工具,凭借简洁的界面和强大的功能,深受开发者喜爱。它支持发送各种HTTP请求(GET、POST、PUT等),轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验,适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作,Postman for Mac都能提升API开发效率,是ma
非删不可?那怎么安全地手动控制
极少数情况必须手动干预,比如测试服务端对错误 Content-Length 的容错能力,或模拟某些老旧客户端行为。这时务必确保字节数精确:
- 用
curl -s -o /dev/null -w "%{size_upload}"测原始 body 字节数(Linux/macOS) - 在 Postman 中切到
raw模式,粘贴 body 后用在线工具(如 https://www.soniacorner.com/utf8-byte-counter/)查 UTF-8 字节数 - 若 body 含中文、emoji 或特殊符号,别信编辑器显示的“字符数”,一定要按 UTF-8 字节算
- 设置完后,用
curl -v对比请求头和 body 是否真正匹配
顺带一提:Transfer-Encoding: chunked 能绕过 Content-Length 校验,但仅适用于 HTTP/1.1 且服务端支持分块传输——Spring Boot 默认不开启,强行加可能导致 400 错误。
Response 的 Content-Length 设错也会卡 Postman
这问题常被忽略:后端代码里硬编码了 response.setHeader("Content-Length", "10240"),但实际写出去的文件或字节数组只有 8192 字节。Postman 会死等剩下的 2048 字节,直到超时。
排查路径:
- 看响应 Headers 里
Content-Length和Content-Type是否合理(比如下载 PDF 却返回text/plain) - 用
curl -I查响应头,再用curl -s | wc -c算真实响应体长度,两者对比 - 如果是 Spring Boot,检查是否用了
ResponseEntity但又手动 setHeader,重复设置会导致不一致
根本解法:让框架自动算。Spring Boot 返回 ResponseEntity 或 Resource 时,它会自动计算并设置 Content-Length;自己写 OutputStream 时,别碰这个 header。










