最直接有效的办法是手动触发新 Token 获取并确认刷新链路完整：检查 refresh_token 是否过期或被吊销、Client 凭据是否正确、Scope 是否含 offline_access、清除 Postman 缓存后点击 “Get New Access Token”，并确保环境变量同步更新 access_token 和 refresh_token。
Postman 里 Token 失效后不能自动续命，必须主动干预——最直接有效的办法是手动触发新 Token 获取，并确认刷新链路是否完整。
为什么点击 “Refresh access token” 没反应
Postman 的 OAuth 2.0 面板上 “Refresh access token” 按钮本质是向授权服务器发一个 grant_type=refresh_token 请求。它失败通常不是按钮问题，而是底层条件不满足：
-
refresh_token已过期或被吊销（OAuth 服务器通常设 7–90 天有效期，部分平台如 Azure AD 默认 90 天） - 授权服务器返回
invalid_grant，说明refresh_token不再可用，必须重走授权流程 - Postman 缓存了旧的 Token 记录，导致界面显示“已授权”，但实际请求头仍带失效值
- 环境变量中
access_token和refresh_token值不同步，比如只更新了前者，后者仍是空或错的
手动获取新 Token 的标准操作路径
绕过刷新机制、直取新凭证，是最稳妥的兜底方式：
- 进入目标 Collection 的 Authorization 选项卡，选类型为
OAuth 2.0 - 确认
Client ID、Client Secret、Auth URL、Access Token URL全部填写正确（尤其注意协议是https，端口是否遗漏） - 在
Scope栏明确填入offline_access（否则 Google、Azure 等平台默认不发refresh_token） - 点击
Get New Access Token，完成登录/授权跳转 - 成功后，勾选
Request access token locally并点击Use Token，确保它写入当前环境变量而非仅临时缓存
Pre-request Script 自动续命的关键检查点
如果用脚本实现“请求前自动刷新”，容易忽略几个硬性前提：
- 脚本里调用
pm.sendRequest刷新时，必须等待回调完成再执行原请求——Postman 不支持 await，需用回调嵌套或 Promise 封装 - 判断 Token 是否该刷新，不能只靠时间戳（
exp字段），还要捕获响应错误：若收到401+{"error":"invalid_token"}，说明已失效，应立刻刷新 - 刷新成功后，必须同步更新两个变量：
pm.environment.set("access_token", newToken)和pm.environment.set("refresh_token", newRefresh)，缺一不可 - 别把
refresh_token存在pm.globals里——全局变量跨环境污染风险高，且无法配合环境快速切换
Token 更新后仍 401 的隐蔽原因
即使新 Token 已写入环境变量，请求仍报 401 Unauthorized，大概率是以下三处之一没对齐：
- 请求头中的 key 名不匹配：后端要的是
X-Auth-Token，你却设了Authorization: Bearer {{access_token}} - Collection 级 Authorization 设置为
Inherit auth from parent，但父级（Collection）本身没配认证类型，或配了却没填{{access_token}} - Postman Console 里看到请求头已带 Token，但值是
{{access_token}}字面量——说明环境未激活，或变量名拼错（比如存的是token，引用的是{{access_token}}）
Token 管理真正的复杂点不在“怎么换”，而在“换完之后谁在用、怎么用、用对没”。每次更新后，务必打开 Postman Console 查一眼最终发出的请求头，确认变量已被真实解析，而不是停留在占位符状态。
