Postman修改请求头需禁用原头再新增，不可直接编辑系统自动生成的只读头（如form-data或JSON模式下的Content-Type）；Bulk Edit可批量导入头，环境变量和Preset更适合长期复用。
Postman 中修改已有请求头不是“覆盖编辑”，而是“先删后加”或“启用/禁用切换”——尤其新版 Postman 默认对部分系统自动生成的头（如 Content-Type）做了只读保护，直接双击改值会失效。
为什么改不了 Content-Type 或其他头？
新版 Postman（v10+）会对某些自动注入的请求头添加灰色禁用标记（如 Content-Type 在 form-data 或 raw JSON 模式下），此时该行 Key-Value 左侧的复选框是取消状态，你无法编辑 Value 栏。强行输入也不会生效，发送时仍以 Postman 自动计算的值为准。
- 常见触发场景：
Body选了form-data→Content-Type被自动设为multipart/form-data; boundary=xxxx，且不可手动修改 -
Body选了raw+JSON→ 自动加Content-Type: application/json，但如果你在 Headers 里另加了一行同名头，Postman 会按“最后启用的一行”生效，容易冲突 - 错误现象：改完点 Send，用 Console 查看实际发出的请求，发现头没变，或出现两个
Content-Type
正确修改已有请求头的三步操作
不是双击改，而是通过启用/禁用+新增组合完成：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 找到要修改的头（例如当前显示
Content-Type:application/json，但你想改成application/json; charset=utf-8） - 点击该行左侧的复选框，取消勾选（即禁用这行）
- 在下方空白行的
Key栏输入Content-Type，Value栏输入新值application/json; charset=utf-8，再勾选其左侧复选框 - 如果原头是系统自动生成的（比如 form-data 下的
Content-Type），你**不能也不应修改它**；需要额外头就另加一行，比如X-Client-Version
批量替换或清理请求头用 Bulk Edit
适合一次调整多个头，或从抓包工具粘贴原始头信息：
- 点击 Headers 右上角的
Bulk Edit按钮 - 粘贴格式为
key: value的纯文本（每行一组，冒号后带空格），例如：Authorization: Bearer abc123 Accept: application/json X-Trace-ID: {{guid}} - 点
Update，Postman 会自动解析并转换成 Key-Value 表格，已存在的 key 会被覆盖（前提是勾选状态一致） - 注意：
Bulk Edit不会保留原有禁用状态，所有导入的头默认启用；导入后务必检查是否误启用了不该发的头
环境变量和预设头更适合长期复用
手动改单个请求头是临时方案，真正在意效率和一致性，就得绕过“改”这个动作：
- 用
Preset保存常用组合（如 “Auth + JSON”），后续请求一键套用，无需逐个编辑 - 把 token、API 版本等动态值存在环境变量里，Headers 中写
Authorization: Bearer {{auth_token}}，换环境自动刷新 - 在集合（Collection）层级的
Pre-request Script中统一注入头：pm.request.headers.add({key:'X-Request-Time', value: new Date().toISOString()});这样整个集合所有请求都自带时间戳，不用每个都设
真正容易被忽略的是：Postman 的头生效顺序依赖“启用状态 + 表格顺序”，而不是你肉眼看到的排列。禁用某行后新加的同名头，哪怕在表格底部，只要启用，就会覆盖前面所有启用的同名头——这点在调试 400/403 错误时特别关键。
