Pre-request Script 中应优先使用 upsert() 而非 add() 设置 Header，因其幂等性可避免重复 Authorization 等导致 400 错误；但需注意大小写敏感、不可覆盖自动生成头（如 multipart boundary），X-Trace-ID 等需唯一 Header 应先 all() 遍历判断再注入；90% 授权场景应改用 Collection Authorization 面板配合变量，而非脚本手动设 Header。
Pre-request Script 中用 upsert() 而非 add()
直接调用 pm.request.headers.add() 是最常见错误来源：它不检查是否已存在同名 Header，每次执行都新增一条，导致重复 Authorization、重复 Accept，服务器可能直接返回 400。而 upsert() 会先查找 key 是否存在，存在则更新 value，不存在才新增——这才是幂等操作。
但注意：upsert() 对大小写敏感（"authorization" 和 "Authorization" 被视为不同 key），且无法跳过系统自动生成的头（如 multipart/form-data 的 Content-Type）。
实操建议：
- 始终用首字母大写的标准写法，例如
upsert({key: "Authorization", value: "Bearer " + token}) - 避免在脚本里手动设置
Content-Type，尤其上传文件时——Postman 自动注入的带boundary的值不能被覆盖 - 如果需要强制覆盖（比如调试时绕过默认值），先
remove()再upsert()，但仅限非常明确的场景
判断 Header 是否已存在再决定是否注入
有些 Header 必须“只加一次”，比如 X-Request-ID 或 X-Trace-ID，重复会导致后端链路追踪混乱。此时不能依赖 upsert()，得主动查。
pm.request.headers.all() 返回当前所有 Header 的数组，可遍历比对：
const headers = pm.request.headers.all();
const hasXTraceID = headers.some(h => h.key === "X-Trace-ID");
if (!hasXTraceID) {
pm.request.headers.upsert({key: "X-Trace-ID", value: Date.now().toString()});
}
这个逻辑比单纯 upsert() 更安全，但代价是多一次遍历——对单次请求影响可忽略，但在高频率自动化测试中，建议封装成复用函数并缓存判断结果。
常见踩坑点：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
pm.request.headers.all()在 Pre-request Script 中返回的是「当前已加载的 Header」，不包含 Collection 层面继承来的 Header（比如你在 Collection 设置了 Bearer Token，它不会出现在这个数组里） - 不要用
includes()直接查字符串，Header key 可能有空格或大小写变体 - 若需跨环境差异化注入（如仅 dev 域名加
X-Debug），记得先读pm.request.url.host做条件判断
用 Collection 级变量 + Authorization 面板替代脚本设 Header
90% 的 Authorization 场景根本不需要写脚本——Collection 的 Authorization 面板会自动注入 Authorization 头，并且优先级高于 Headers 标签页里的手动条目。如果你在 Headers 里又手写了一条 Authorization: Bearer xxx，Postman 实际发出去的只会是面板设置的那个，但你调试时看到 Headers 页面有两条，极易误判。
正确做法是：
- 在 Collection 设置
Authorization类型为Bearer Token，Token 值填{{access_token}} - 在 Pre-request Script 中只负责刷新
access_token变量（比如调用登录接口后提取并pm.environment.set("access_token", ...)） - 彻底删除 Headers 标签页里任何手动写的
Authorization条目
这样既避免重复，又解耦了认证逻辑和请求构造，还能让所有子请求自动继承——包括后续用 pm.sendRequest() 发起的子请求，只要它们属于同一 Collection 上下文。
全局 Header 冲突时如何快速定位？
当发现某个 Header 总是“莫名出现”或“怎么删都还在”，大概率是多个源头叠加导致的：Collection 继承 + 环境变量引用 + Pre-request Script 三者同时生效。
最有效的排查方式是打开 Postman Console（View → Show Postman Console），发送请求后点开该请求详情，在 Headers 区域看每条 Header 后面标注的来源，例如：
Authorization: Bearer abc123 [from collection auth]X-Custom: test [from pre-request script]Content-Type: multipart/form-data; boundary=xxx [auto-generated]
这个来源标记不会骗人。真正难处理的是那些没标记的条目——通常是手动在 Headers 标签页添加的，但被其他机制覆盖后“看起来像没生效”，其实它还在那里占着位置。
所以每次修改 Header 行为前，先清空 Headers 标签页所有条目，只保留必要且明确知道来源的几项；脚本里也别图省事写 add()，宁可多写两行判断。
