Postman自动刷新失败时应先查看Console错误响应,常见原因包括invalid_grant(需重授权)、invalid_client(检查密钥)、unsupported_grant_type(服务器不支持)等;可手动发raw请求或用Pre-request Script自动刷新,并注意refresh_token本身也会过期。

Postman自动刷新失败时,先看Console里的错误响应
Postman点击“Refresh Access Token”没反应或报错,不是配置错了就是服务器拒绝了。真正有用的线索藏在 View > Show Postman Console 里——那里会显示完整的HTTP请求和响应体。
常见错误码和对应动作:
-
invalid_grant:refresh_token 已过期或被撤销,必须重新走授权流程(比如点Get New Access Token) -
invalid_client:Client ID或Client Secret不匹配,检查是否拼写错误、大小写敏感、或服务端已轮换密钥 -
unsupported_grant_type:授权服务器根本不支持refresh_token流程(如某些只用client_credentials的场景) - 空响应或超时:token 端点地址(
Access Token URL)填错了,或网络策略拦截了 POST 请求
手动发请求刷新 token,绕过Postman GUI限制
Postman 内置的 OAuth 2.0 表单对 scope、header、body 格式控制较死,很多定制化服务(如 Amazon SP-API、Azure AD B2C)要求精确控制参数位置。直接用 raw request 更可靠。
新建一个 POST 请求,目标地址填你的 token 端点(例如 https://api.amazon.com/auth/o2/token),设置如下:
- Headers:
Content-Type: application/x-www-form-urlencoded - Body(x-www-form-urlencoded):
-
grant_type=refresh_token -
refresh_token={{refresh_token}}(从环境变量读取) -
client_id={{client_id}} -
client_secret={{client_secret}}
-
注意:有些服务(如 Google)还强制要求 scope 参数与首次获取 token 时完全一致,少一个空格都会返回 invalid_scope。
前置脚本自动刷新:避免每次测试都卡在 401
如果你跑的是 Collection,且里面几十个请求都依赖同一个 token,靠手动刷新不现实。用 Pre-request Script 实现“按需续命”:
Postman 12.27.7 Windows x64 官方安装包,适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力,以及接口规范标签管理改进,适合受限网络测试与规范资源组织场景。
在 Collection 的 Pre-request Script 里写:
const accessToken = pm.environment.get("access_token");
const expiresAt = pm.environment.get("expires_at");
<p>if (!accessToken || !expiresAt || Date.now() >= expiresAt * 1000) {
const refreshToken = pm.environment.get("refresh_token");
const url = pm.environment.get("token_url");</p><pre class='brush:java;toolbar:false;'>pm.sendRequest({
method: 'POST',
url: url,
header: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: {
mode: 'urlencoded',
urlencoded: [
{ key: 'grant_type', value: 'refresh_token' },
{ key: 'refresh_token', value: refreshToken },
{ key: 'client_id', value: pm.environment.get("client_id") },
{ key: 'client_secret', value: pm.environment.get("client_secret") }
]
}
}, (err, res) => {
if (err) throw err;
const data = res.json();
pm.environment.set("access_token", data.access_token);
pm.environment.set("expires_at", Math.floor(Date.now()/1000) + data.expires_in);
});}
关键点:
- 别依赖
expires_in算绝对时间,要转成秒级时间戳存到expires_at -
pm.sendRequest是异步的,原始请求不会等它完成——所以这个脚本只适合放在 Collection 层,靠变量更新影响后续所有请求 - 如果 token 端点需要 Basic Auth,把
Authorizationheader 加进pm.sendRequest的header字段里,值为"Basic " + btoa(client_id + ":" + client_secret)
refresh_token 本身也会过期,而且通常不提示
很多人以为 refresh_token 是“永久有效”的,其实不是。它的有效期由授权服务器决定,常见情况有:
- Azure AD 默认 90 天,且“不活跃即失效”(连续 90 天没用就作废)
- Auth0 可配置,但默认是 30 天
- Spring Security OAuth2 的
oauth_refresh_token表里,expiration字段明确存着过期时间
这意味着:即使你每天都在刷新 access_token,某天突然失败,大概率是 refresh_token 本身已经不可用了。这时候没有捷径,只能让用户重新登录或走完整授权码流程——这也是为什么生产环境建议在前端保留登录态兜底逻辑,而不是全押在 refresh_token 上。
















