Pre-request Script重复添加Authorization头会导致双Bearer错误，表现为服务端返回400或401且抓包显示“Bearer token Bearer token”；根本原因是界面Bearer Token配置与脚本中headers.upsert()叠加执行。
Pre-request Script里重复添加Authorization头会导致双Bearer
最常见的现象是：请求发出去后，服务端返回400 Bad Request或401 Unauthorized，但抓包发现Authorization头里出现了两个Bearer，比如：Authorization: Bearer ey... Bearer ey...。这不是Token本身错了，而是Postman在不同层级叠加设置了头。
根本原因是：你既在Authorization选项卡里选了Bearer Token并填了值，又在Pre-request Script里手动调用了pm.request.headers.add()或upsert()去加同一个头——两者不冲突，而是叠加执行。
- 检查当前请求的
Authorization选项卡：如果Type选的是Bearer Token，且Token输入框非空，就说明界面层已启用自动注入 - 打开该请求（或所属Folder/Collection）的
Pre-request Script，搜索Authorization、headers.add、headers.upsert等关键词 - 若脚本中已有类似
pm.request.headers.upsert({key: 'Authorization', value: `Bearer ${token}`})，必须删掉或注释掉——让位给界面配置
用Tests脚本主动校验Authorization头内容
光靠肉眼检查请求头容易漏，尤其当脚本逻辑复杂、多环境切换频繁时。可以在Tests里加一段轻量校验，每次发完请求立刻反馈是否合规。
把下面这段代码粘贴进任意请求的Tests标签页，它会在控制台输出实际发送的Authorization头，并判断是否含且仅含一个Bearer：
const authHeader = pm.request.headers.get('Authorization');
console.log('实际发送的 Authorization:', authHeader);
if (authHeader) {
const bearerCount = (authHeader.match(/Bearer\s+/g) || []).length;
pm.test('Authorization头中Bearer前缀应只出现一次', () => {
pm.expect(bearerCount).to.eql(1);
});
}
这个检查不会影响请求本身，但能快速暴露脚本误写、环境变量污染或配置残留问题。
Collection级别配置+脚本混合使用时的优先级陷阱
当你在Collection上设了Authorization: Bearer {{access_token}}，又在某个Request的Pre-request Script里动态更新access_token，看似合理，实则埋雷：Collection级认证会无条件覆盖脚本里对Authorization头的操作，除非你显式禁用。
- Collection设置的
Authorization类型为Bearer Token时，它会在所有子请求发出前自动注入，不管脚本有没有动头 - 如果你需要脚本完全掌控Token注入（比如要做有效期判断、刷新逻辑），必须把Collection和Folder的
Authorization类型改为No Auth - 然后统一由Pre-request Script通过
pm.request.headers.upsert()设置头——这样才可控、可调试、可加日志 - 别依赖
pm.environment.set('access_token', ...)后坐等界面自动读取，那只是“看起来生效”，实际执行顺序和覆盖逻辑不透明
Token字符串本身带Bearer前缀是典型错误源头
有些登录接口返回的JSON里，token字段值已经是"Bearer xxxxx"这种完整字符串（而非纯token）。如果直接存进环境变量再拼接，就会变成Bearer Bearer xxxxx。
在登录请求的Tests脚本里，务必做清洗：
const json = pm.response.json();
let rawToken = json.access_token || json.token;
// 剥离可能存在的Bearer前缀
if (typeof rawToken === 'string' && rawToken.trim().startsWith('Bearer ')) {
rawToken = rawToken.trim().substring(7);
}
pm.environment.set('access_token', rawToken);
这个步骤不能省。很多团队踩坑都是因为后端返回格式不一致（开发环境没前缀、测试环境有前缀），而脚本没做兼容处理。
真正难的不是写对一行upsert，而是理清Postman四层认证机制（界面配置、环境变量、脚本设置、请求继承）之间的覆盖关系。一旦混用，错误表现非常隐蔽——请求看着成功，但权限不对；或者偶尔失败，日志里却找不到线索。建议所有涉及Token自动管理的集合，都配上Tests里的头校验逻辑，这是最廉价的兜底手段。
