Postman不直接显示填写与实际发出的Header差异，需通过Postman Console或代理抓包（如Chrome Interceptor）查看真实请求头；Content-Type、Host、Cookie等字段受工具自动管理，非“所见即所得”。
Postman 本身不直接显示「你填的 Header」和「最终发出去的 Header」之间的差异，它只展示你手动填写的内容。真正发出的请求头可能被自动补全、覆盖或忽略——比如 Content-Type 在 Body 类型切换时被重写，Cookie 在启用「Send cookies」但未配置时被清空，User-Agent 在某些版本里会被强制替换。要确认实际发出的请求头，必须绕过 Postman 的 UI 层，从网络底层抓包或启用其内置调试能力。
用 Postman Console 实时查看原始请求头
这是最轻量、最贴近真实发送行为的方式。Postman Console（不是 DevTools）会记录每次请求的完整原始 HTTP 报文，包括所有被自动添加/修改的 Header。
- 点击右上角 View → Show Postman Console（快捷键
Cmd+Alt+C/Ctrl+Alt+C） - 发起请求后，在 Console 中点开对应条目 → 切到 Request 标签页 → 展开 Headers 区域
- 这里看到的是「真正发出去的」，例如：
content-type: application/json（小写、带分号）、accept: */*（即使你没填）、user-agent: PostmanRuntime/7.40.0（固定值，无法通过 Headers 表格覆盖） - 注意：如果启用了
Automatically persist cookies或设置了Cookie环境变量，Console 里也会显示合并后的cookie值
为什么 Headers 表格里填的 ≠ 实际发出的
Postman 对部分 Header 有强干预逻辑，不是“所见即所得”。常见冲突点：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Content-Type：当你在 Body 选了JSON，Postman 会强制设为application/json; charset=utf-8，即使你在 Headers 表格里写了application/json—— 后者会被忽略 -
Host：由 URL 解析生成，表格里填的无效 -
Connection、Accept-Encoding、Transfer-Encoding：Postman 自动管理，不可手动覆盖 -
Authorization：如果同时在 Headers 表格和 Authorization Tab 里设置了，后者优先；但若 Authorization Tab 选了No Auth，表格里的Authorization才生效 -
Cookie：仅当开启Send cookies（Settings → General）且当前域名有已存 Cookie 时才自动注入；否则表格里写的Cookie才起作用
用代理方式抓包验证（Chrome + Postman Interceptor 或系统代理）
当 Console 不够用（比如想看 TLS 握手、HTTP/2 流、或确认是否被中间件改写），就得用外部工具捕获原始字节流。
- 启动 Chrome，打开
chrome://extensions，安装官方Interceptor插件并启用 - Postman 中点击右上角
Interceptor图标，连接成功后开关置为 ON - 此时 Postman 发出的所有请求都会同步出现在 Chrome 的 Network 面板中，点开任意请求 → Headers → 查看 Request Headers 部分 —— 这是服务器收到的原始内容
- 注意：Interceptor 对 HTTPS 请求支持有限（依赖证书信任），若看到
net::ERR_SSL_PROTOCOL_ERROR，可临时改用系统级代理（如 Charles/Fiddler）并配置 Postman 的 Proxy 设置
真正难的不是“怎么看到”，而是理解哪些 Header 是 Postman 强制托管的、哪些是你可控的、哪些又取决于运行环境（如 Cookie 存储状态）。别依赖 Headers 表格里的勾选框做判断，Console 和抓包才是唯一可信源。
