要确认Postman实际发出的请求头和参数，需用httpbin.org回显验证或Wireshark/Fiddler抓包；Postman界面显示非真实报文，环境变量、预请求脚本、body类型与Content-Type匹配度均影响最终请求。
怎么看Postman实际发出去的请求头和参数
Postman默认不显示原始HTTP请求报文，你看到的“Headers”标签页是它整理后的视图，不是服务端真实收到的内容。要确认实际发出的请求结构，必须启用底层日志或借助外部工具抓包。
常见错误现象：Authorization 头在Postman里显示正常，但后端收不到；Content-Type 设为 application/json，但服务端解析成空体；查询参数在 Params 里填了，URL却没拼上——这些都说明你没验证过真实发出的数据。
- 最直接方式：用
httpbin.org回显服务验证，例如发送 GET 请求到https://httpbin.org/get，响应体中args和headers字段就是服务端实际解析出的内容 - 需要完整原始报文（含换行、空格、大小写细节）时，启动
Wireshark或Fiddler抓包，过滤目标域名，查看 TCP 流中的明文 HTTP 请求 - Postman 自带日志（
View → Developer → Show DevTools (Current View)）只记录部分元信息，不输出原始请求行和完整 header 块，不能替代抓包
POST 请求体为什么没发出去
POST 请求体是否发出，取决于你选的 body 类型和对应设置是否匹配。Postman 不会自动帮你转换格式，也不会报错提示“你填了 raw 但 content-type 没设”，它只是按你选的方式发。
典型场景：你把 JSON 字符串粘贴进 Body → raw，但 Content-Type 请求头没手动加 application/json，或者加错了（比如写成 application/json;charset=UTF-8 但后端严格校验 MIME 类型）。这时服务端可能直接忽略 body，返回 400 或空数据。
-
Body → form-data：适合文件上传或混合字段，Postman 自动设Content-Type: multipart/form-data; boundary=...，无需手填 -
Body → x-www-form-urlencoded：Postman 自动编码键值对，并设Content-Type: application/x-www-form-urlencoded -
Body → raw：完全由你控制内容和Content-Type头，二者必须人工保持一致；JSON 就填application/json，XML 就填application/xml -
Body → binary：只发原始字节流，不加任何 header，需后端明确约定接收方式
环境变量和预请求脚本怎么影响最终请求
环境变量（如 {{base_url}}）和预请求脚本（Pre-request Script）是在请求发出前动态注入的，它们修改的是最终构造出的请求，不是你在界面上看到的静态值。一旦变量未定义或脚本抛错，Postman 会静默替换为空字符串或跳过执行，不会中断发送，但结果往往异常。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
容易踩的坑：{{token}} 在环境里没设置，请求头里就变成 Authorization: Bearer （后面空格都没），后端鉴权失败；脚本里用了 pm.environment.set("uuid", pm.response.json().uuid)，但响应根本不是 JSON 或字段不存在，导致后续请求用 {{uuid}} 时取到 undefined。
- 检查变量是否生效：在地址栏或 Headers 输入框里，把鼠标悬停在
{{xxx}}上，会显示当前解析值；若显示{{xxx}}本身，说明变量未定义或拼写错误 - 调试脚本：在
Pre-request Script里加console.log()，然后打开View → Developer → Show DevTools (Current View)查看控制台输出 - 避免链式依赖：不要让一个脚本的输出强依赖另一个脚本的执行顺序，Postman 不保证多请求间脚本执行时序
响应里看到的 URL 和实际发出的请求 URL 不一致
这是最常被忽略的一点：Postman 的地址栏显示的是你输入的原始 URL，但真正发出的请求 URL 可能已被重定向、代理或环境变量二次处理。尤其当你开启代理（Proxy）或使用 Redirects 设置时，初始请求可能只是跳板。
比如你输的是 http://example.com/api/v1/user，但响应状态码是 302，Location 头指向 https://api.example.com/v1/user，那么 Postman 默认会自动跟随重定向——你看到的响应其实是第二次请求的结果，而第一次的原始请求内容已不可见。
- 禁用自动重定向：在请求设置右上角点击
Settings（齿轮图标），关闭Automatically follow redirects，再发一次，就能在响应中看到原始 302 结果和 Location 头 - 确认是否走代理：检查
File → Settings → Proxy，若启用系统代理或自定义代理，所有请求都会先经过该出口，原始 IP 和 Host 可能被改写 - URL 中的变量替换发生在发送前，不是渲染时：即使你把
{{host}}/user写进地址栏，只要{{host}}解析失败，发出的就是字面量{{host}}/user，而不是报错提醒
真实请求内容永远以服务端接收到的为准，界面显示只是辅助。别信地址栏，别信 Headers 标签页，更别信“我明明填了”。抓一次包，或打一个 httpbin，比反复猜要快得多。
