pm.request.headers.add()是唯一支持的动态添加Header方法；必须在Collection级Pre-request Script中调用，且需选中对应Environment；不可手动设置Content-Type（尤其multipart/form-data场景）。
pm.request.headers.add() 是唯一能从脚本动态加 Header 的方法
Postman 的预请求脚本（Pre-request Script）里不能直接修改 pm.request.headers 对象本身，也不能用赋值或 push；必须调用 add() 方法。这是官方沙箱 API 唯一支持的写法，其他方式（比如 pm.request.headers['Authorization'] = ...）会静默失败，且不报错。
常见错误现象：
- 脚本运行无报错，但请求发出后 Header 没出现
- 误以为
set()或append()存在，实际不存在 - 在 Tests 脚本里调用
add()—— 无效，因为 Tests 在请求发出后执行
正确写法示例：
pm.request.headers.add({
key: "Authorization",
value: "Bearer " + pm.environment.get("access_token")
});
注意：add() 每次只接受一个对象，不能批量传入数组；重复添加同名 key 不会覆盖，而是并存（服务器通常只取第一个，行为不可靠）。
Header 名大小写敏感，但值里含空格要手动补全
HTTP 规范中 Header 名是大小写不敏感的，但 Postman 内部处理时对 key 字符串做精确匹配。虽然 authorization 和 Authorization 实际效果一样，但为避免协作混乱和调试困惑，统一用首字母大写驼峰式（如 Content-Type、X-Request-ID）更稳妥。
值部分要注意：
-
Bearer后必须有且仅有一个空格，写成"Bearer"+token会导致 401 - 如果 token 含特殊字符（如换行、制表符），
pm.environment.get()返回值可能带不可见符，建议先.trim() - 不要在 value 中拼接
\n或\r—— HTTP Header 不允许换行
安全写法：
const token = pm.environment.get("access_token")?.trim();
if (token) {
pm.request.headers.add({
key: "Authorization",
value: `Bearer ${token}`
});
}
全局 Header 脚本必须放在 Collection 级 Pre-request Script
想让整个 Collection 下所有请求都自动带上某个 Header，脚本不能写在单个请求里，也不能写在环境（Environment）或全局（Globals）变量中 —— 那些地方只存数据，不执行逻辑。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
必须操作路径：
- 右键目标 Collection → Edit
- 切换到 Pre-request Script 标签页
- 粘贴脚本（如上示例）
- 确保右上角已选中对应 Environment（否则
pm.environment.get()返回undefined）
容易踩的坑：
- 脚本写在 Request 级 Pre-request Script → 只影响当前请求，不是“全局”
- 忘记选中 Environment →
pm.environment.get()返回空，Header 值变成Bearer undefined - 在 Folder 级写脚本 → 只对该文件夹内请求生效，不是 Collection 全局
multipart/form-data 请求下，别碰自动生成的 Content-Type
上传文件时选了 form-data，Postman 会自动生成类似 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryxxx 的头。这个 boundary 是动态生成的，用于分隔字段与文件内容。
如果你在脚本里手动 add() 一个 Content-Type，或者在 Headers 标签页手动填入，就会覆盖掉原始头，导致服务器无法解析 multipart 数据，返回 400 Bad Request 或空响应。
正确做法：
- 完全不要设置
Content-Type头（无论是手动还是脚本） - 只添加其他必要头，比如
Authorization、X-Upload-Source - 如果 API 文档明确要求自定义
Content-Type（极少见），说明它不走标准 multipart 流程，应改用binary或raw模式
验证是否被覆盖：发请求前点开 Postman 底部的 Console，查看实际发出的请求头，确认 Content-Type 是否仍含 boundary= 参数。
复杂点在于：Header 的生效时机、作用域、与自动机制的冲突，三者叠加后问题常不报错却失效。最省事的排查路径是——打开 Console 看真实发出的请求头，而不是只信脚本有没有跑。
