Postman配置Bearer Token需自动提取、环境变量存储和手动刷新:从登录响应提取Token存入环境变量,Authorization中引用{{accessToken}},Pre-request Script无需重复加Header,Auto Refresh对普通登录无效。

Postman配置Bearer Token不是“填个字符串就完事”,关键在于Token从哪来、怎么存、何时更新——填错位置或忽略刷新逻辑,90%的401错误都出在这三步。
Token必须从登录响应里自动提取,不能手动复制粘贴
手动复制Token看似快,但一过期就得重登、重找、重填,尤其在多环境(dev/staging/prod)切换时极易填串。正确做法是让Postman自动从登录接口响应中提取并存入变量:
- 在登录请求的
Tests标签页里写脚本,比如后端返回{"code":200,"result":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."},就用:const res = pm.response.json();<br>if (res.code === 200) {<br> pm.environment.set("accessToken", res.result);<br>} - 确保环境已启用:右上角“眼睛”图标选中你创建的环境(如
dev-env),否则pm.environment.set()不生效 - 别用
pm.variables.set()或全局变量——它不隔离环境,测试生产混用会出安全问题
集合级Bearer Token要引用环境变量,不是硬编码
在集合(Collection)的 Authorization 选项卡里选 Bearer Token 类型后,Token 输入框必须填 {{accessToken}},而不是直接粘贴一长串JWT。原因很实际:
- 硬编码Token会导致所有请求共用同一值,一旦过期,全部报401,还得逐个检查哪里填错了
- 引用变量后,只要登录接口跑一次,整个集合所有请求自动带上最新Token
- 如果后端返回的是
data.token或token.access_token这类嵌套结构,脚本里得写全路径:res.data.token,否则变量为空,请求头变成Authorization: Bearer(空值),照样401
Pre-request Script加Header是常见误区,多数情况不需要
有人看到文档说“Spring Security要求Header里带 accessToken”,就去集合的 Pre-request Script 里手动加:pm.request.addHeader("accessToken", pm.environment.get("accessToken"))。这反而容易出问题:
- Bearer Token标准协议要求的是
Authorization: Bearer xxx,不是自定义accessToken头——后端没配白名单的话,这个头会被直接忽略 - 重复添加会导致两个认证头共存,部分网关(如Kong、API Gateway)会拒绝处理
- 真正需要手动加Header的场景极少,比如后端非标实现、或需同时传多个Token(如
X-User-ID配合Authorization),否则一律走Authorization选项卡配置
Auto Refresh Token功能基本不可靠,别依赖它
Postman界面里有 Auto Refresh Token 开关,但实际中它只在“通过OAuth 2.0 flow获取Token”时才有效。如果你的Token来自普通登录接口(POST /login),这个开关点了也没用——它不会自动重发登录请求。
- 真要自动续期,得自己写逻辑:在集合的
Pre-request Script里判断pm.environment.get("accessToken")是否为空或过期(需解析JWT的exp字段),再调用pm.sendRequest()模拟登录 - 更稳妥的做法是把登录请求放在集合最前面,测试前手动点一次;或者用Newman做CI时,把登录步骤作为独立脚本前置执行
- 别忘了检查Token是否真被设进去了:发送任意请求后,在
Console(View → Show Postman Console)里看发出的请求头,确认是Authorization: Bearer eyJ...而不是Authorization: Bearer {{accessToken}}(说明变量没解析成功)
最常被忽略的一点:Postman不会帮你解析JWT有效期,也不会主动告诉你Token过期了——它只管把变量值塞进请求头。所以每次遇到401,第一反应不该是怀疑后端,而是打开Console看发出去的Authorization头到底是什么内容。











