Postman 里看不到原始 JSON 请求体，本质是编辑输入阶段存在非法字符（如中文引号）、未启用 raw→JSON 模式或 Content-Type 未设为 application/json；需通过 Code→curl 验证实际发送内容，并在 Go 后端解码前用 io.ReadAll + io.NopCloser 重置 req.Body，且必须检查 json.Decoder 错误。
Postman 里看不到原始 JSON 请求体？先确认 Body 是否被正确读取
Postman 本身不直接显示“已发出的原始字节流”，你看到的只是它内部构造并发送前的内容。如果你怀疑发出去的不是预期 JSON，问题往往出在编辑界面输入阶段，而非发送后“丢失”了什么。关键要区分：是 Postman 没按你写的发，还是你写的本身就不是合法 JSON。
常见错误现象包括：400 Bad Request、后端日志报 invalid character '' looking for beginning of object key string、或 Go 后端解析后字段全为空。这些几乎都指向一个事实：你在 Body 编辑框里粘贴或手敲的 JSON 包含不可见非法字符（比如中文引号 “”、全角冒号 ：、BOM 头、或末尾多了一个逗号）。
- 务必在 Body → raw → JSON 模式下输入，此时 Postman 会实时语法高亮——红色波浪线就是最直接的警告
- 不要从微信、Word、Notepad++（未设 UTF-8 无 BOM）等地方直接复制 JSON；用 VS Code 或 Sublime Text 粘贴后手动检查引号是否为 ASCII
" - 如果必须从外部粘贴，先粘到纯文本编辑器（如记事本），再复制到 Postman，可过滤掉富文本格式
如何验证 Postman 实际发出了什么？抓包是最可靠方式
想 100% 确认网络层真正发出的字节，不能依赖 Postman 界面显示，得用外部工具捕获 HTTP 流量。本地开发最常用的是 Wireshark 或系统级代理 mitmproxy，但对多数人来说，curl 命令生成 + 手动比对更轻量、更可控。
Postman 底部有 “Code” 按钮（三个点 → “Code”），点击后选择 curl (bash)，它会生成一条完整命令，包含所有 headers 和 raw JSON。把这条命令复制出来，在终端执行前，先肉眼检查 -d '{...}' 部分是否和你预期一致——尤其是引号、转义、换行是否被 shell 正确处理。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 若 JSON 含双引号或变量，
curl -d中建议用单引号包裹整个 JSON 字符串，避免 shell 解析干扰 - 生成的
curl命令里若有-H "Content-Type: application/json"，说明 Postman 确实按 JSON 模式发送；若缺失，说明你没选对 Body 类型或手动删了 header - 执行该
curl命令，和服务端返回结果对比——如果 curl 成功而 Postman 失败，基本锁定是 Postman 界面输入或缓存问题
Go 后端收到空结构体？别急着怪 Postman，先看 req.Body 状态
很多开发者在 Go 服务里发现 json.NewDecoder(req.Body).Decode(&v) 后 v 字段全零，第一反应是“Postman 没发对”。但更大概率是：JSON 本身合法，但 req.Body 已被提前读取过一次（比如中间件、日志打印、或你自己调了 io.ReadAll 又没重置），导致解码器读到 EOF。
此时 req.Body 不是“空”，而是“已耗尽”。打印 req.Body 接口值（如 fmt.Printf("%v", req.Body)）输出类似 &{%!s(*io.LimitedReader=)} 的内容，这并非数据异常，只是你试图打印一个已关闭的 reader 接口。
- 调试时想看原始 JSON，必须在任何解码操作前，用
bodyBytes, _ := io.ReadAll(req.Body)一次性读完，再用req.Body = io.NopCloser(bytes.NewReader(bodyBytes))重置 - 永远检查
json.NewDecoder的返回错误，if err != nil { log.Println("JSON decode error:", err) }—— 错误信息会明确告诉你卡在哪一行哪个字符 - Postman 发送的 Content-Type 是
application/json，但 Go 的http.Request.ParseForm()会拒绝非application/x-www-form-urlencoded类型，调用它会导致 body 被丢弃，切勿混用
Postman 自带的 “Send and Download” 不解决根本问题
有人尝试用 Postman 的 “Send and Download” 功能保存响应，误以为也能保存请求原文。其实它只保存响应体，不记录请求原始 payload。真正的调试闭环是：在 Postman 写好 JSON → 点 Code 看 curl → 复制 curl 到终端执行并观察结果 → 若失败，把 curl 命令里的 JSON 单独拿出来用 jq . 校验格式（echo '{"name":"foo"}' | jq .）→ 格式 OK 再回看 Go 日志里的 decode error。
最容易被忽略的一点是：Postman 的 “JSON” 下拉选项只是个提示，它**不会自动修正**你输入的非法 JSON。它只负责把编辑框内容原样发出去，并设置 header。所以那个红色波浪线，是你唯一能依赖的实时校验器——只要它还红着，就别点 Send。
