删掉手动设置的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<byte></byte> 或 Resource 时，它会自动计算并设置 Content-Length；自己写 OutputStream 时，别碰这个 header。
