Collection级Bearer Token认证首选方式是右键Edit→Authorization选Bearer Token并填{{accessToken}}，需提前在环境或Collection变量中定义；登录接口Tests脚本自动提取token并用pm.environment.set()存入环境变量；若后端要求自定义Header则改用Pre-request Script注入；环境切换后token未更新需检查变量作用域、环境启用状态及Console中脚本执行情况。
Collection 级别设置 Bearer Token 认证最直接
Postman 的集合（Collection）本身支持统一认证配置，这是让整个集合共用 Token 的首选方式。它不依赖环境变量或脚本，配置一次，所有子请求自动继承，且逻辑清晰、不易出错。
操作路径：右键点击 Collection → Edit → 切换到 Authorization 选项卡 → Type 选 Bearer Token → Token 输入框填 {{accessToken}}（注意双大括号是变量引用语法）。
关键点：
- 这个
{{accessToken}}必须提前在环境（Environment）或 Collection 变量中定义好，否则会发空 Token 导致 401 - 如果同时存在 Environment 和 Collection 变量同名，Postman 优先使用 Environment 变量
- 子请求默认开启
Inherit auth from parent，无需额外设置；若手动改成其他类型，就会中断继承
登录后自动更新 accessToken 变量的 Tests 脚本写法
Token 不是静态值，过期后必须重新获取并刷新。靠手动复制粘贴极易出错，必须用 Tests 脚本自动提取并写入变量。
在登录接口的 Tests 标签页中，粘贴以下代码（适配常见返回结构）：
const res = pm.response.json();
if (res.code === 200 || res.status === 'success') {
pm.environment.set('accessToken', res.data?.token || res.token || res.access_token);
}
常见坑点：
-
pm.environment.set()写的是环境变量，不是 Collection 变量；如用pm.collectionVariables.set()，则 Collection 级认证里得改用{{token}}且确保没同名环境变量覆盖 - 响应字段名五花八门：
token、access_token、data.token、result.accessToken……务必先点开登录响应体确认真实路径 - 没加
if判断就直接 set，会导致登录失败时把变量设为空，后续所有请求都带无效 Token
Pre-request Script 补位：当 Authorization 不适用时
某些后端不认标准 Authorization: Bearer xxx，而是要求自定义 Header，比如 X-Auth-Token 或 accessToken。这时 Collection 级的 Bearer Token 类型就失效了，必须用脚本注入。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
在 Collection 的 Pre-request Script 中写：
const token = pm.environment.get('accessToken');
if (token) {
pm.request.headers.add({key: 'X-Auth-Token', value: token});
}
注意事项：
- 不能写成
pm.request.headers.upsert()—— Postman 当前版本不支持该方法，会报upsert is not a function - Header 名称大小写敏感，
x-auth-token和X-Auth-Token在部分服务端会被视为不同字段 - 此方式绕过了 Postman 的认证管理逻辑，断言、调试面板里的 Auth 区域不会显示，排查问题时容易忽略来源
环境切换时 token 没自动更新？检查变量作用域和启用状态
多人协作或跨环境测试时，常出现“切了环境，但请求还是发旧 Token”。这不是 Bug，而是变量未按预期生效。
排查顺序：
- 确认右上角眼睛图标旁显示的环境名，是否为你刚编辑的那个（比如
dev而非default） - 进入该环境编辑页，检查
accessToken的值是否为空或过期；Postman 不会自动清空变量，旧值会一直残留 - 打开 Console（View → Show Postman Console），发送登录请求，看
Tests脚本是否真的执行并调用了pm.environment.set() - 避免混用
pm.environment.set()和pm.variables.set()—— 后者是临时变量，只在当前请求生命周期有效，无法被其他请求读取
真正麻烦的从来不是配置步骤，而是变量在 Environment / Collection / Local 三层间静默覆盖——只要有一个地方写错作用域，整个链路就悄无声息地断掉。
