200状态码但body为空，说明服务端未写响应体，需检查Content-Length是否为0及Content-Type是否匹配；204状态码本就不应有body，属正常设计；gzip解码失败也会导致Postman显示空白。
响应状态码是200但body为空，先看Content-Length和Content-Type
Postman里看到Headers有值、Body却空白，不是前端解析问题，而是服务端根本没写响应体。打开Network面板点开该请求，直接看Response标签页底部的原始文本——如果连{}或[]都没有，就说明后端返回了空body。
此时重点检查两个响应头：
-
Content-Length是否为0：是，则服务端HTTP状态码虽为200，但未调用write()或send()类方法，属于后端逻辑遗漏 -
Content-Type是否为application/json等可读类型：若为text/plain或application/octet-stream且body为空，可能是服务端误设了类型但没写内容
别急着改Postman设置，先用curl -v复现，确认是不是服务端行为。
状态码是204时，正文为空是设计使然，不是bug
204 No Content是HTTP标准状态码，明确表示“请求已成功处理，但服务器不返回任何响应体”。很多RESTful接口在DELETE、PATCH成功后都用这个状态码。
遇到这种情况：
- 立刻停止排查
data字段或JSON解析逻辑——它本来就不该有body - 查接口文档确认该路径是否定义为
204语义，比如DELETE /users/{id}通常不返回数据 - 前端代码里不能对
response.json()做无条件调用，要先判断response.status !== 204
Postman显示“Body is empty”只是忠实地反映了协议约定，不是异常。
Postman自动解码gzip导致body显示为空白
当响应头含Content-Encoding: gzip，但Postman解码失败时，Body标签页可能显示为空白或乱码，而非原始二进制流。这不是服务端没发数据，而是Postman卡在解码环节。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
验证方式很简单：
- 切换到Postman的
Body标签页，右键选择Save Response to File，保存为raw.bin - 用
file raw.bin（Linux/macOS）或certutil -hashfile raw.bin SHA256（Windows）确认文件非空 - 若文件大小 > 0，说明数据已收到，只是Postman渲染失败
临时解决：进入Settings → General，关闭Automatically decode compressed responses，再重发请求。Body会显示原始字节流，可手动用gunzip -c raw.bin验证。
服务端写了200但没写body，属于需推动修复的缺陷
状态码200 + Content-Length: 0 + Content-Type: application/json这种组合，违反HTTP语义：既然声明是JSON，又不给任何JSON内容，客户端无法区分“空对象”还是“服务端忘了写”。
这类问题常见于以下场景：
- Spring Boot中误用
@ResponseStatus(HttpStatus.OK)但没加@ResponseBody - Express里调用了
res.sendStatus(200)而非res.json({}) - Go Gin中只写
c.Status(200)，漏掉c.JSON(200, data)
必须向后端提供trace_id和完整请求/响应头截图，推动其改为返回{}或[]，而不是空body。否则所有客户端都要额外兼容这个非标行为。
