Postman 不自动识别 Token 过期，需在 Tests 脚本中结合状态码（401/403）与响应体字段（如 code、error）按后端约定判断；Pre-request Script 中解码 JWT exp 不可靠，因服务端可提前吊销；Token 刷新需手动或通过 Collection 分层实现。
Postman 本身不会自动识别 Token 是否过期，它只负责发送你配置的请求；真正判断 Token 是否失效，必须依赖服务端返回的状态码、响应体结构或响应头。直接看 401 或 403 并不足够——你需要结合具体接口的错误约定来确认是不是 Token 过期导致的失败。
怎么在 Tests 脚本里判断 Token 过期
很多后端对 Token 失效有自定义响应格式，比如返回 {"code": 401, "msg": "token expired"} 或 {"error": "invalid_token"}。硬套 HTTP 状态码会漏判（例如有些服务对过期 Token 仍返回 200，但 body 里明确标出失效）。
- 先用
pm.response.code检查状态码是否为401或403，但这只是初步线索 - 再用
pm.response.json()解析响应体，检查关键字段：code、error、message是否匹配你项目约定的过期标识（如code === 998、error === "invalid_token"） - 如果响应体不可读（比如空或非 JSON），要加
try/catch防止脚本崩溃：try { const res = pm.response.json(); if (res.code === 998 || res.error === "invalid_token") { console.log("Token 已过期"); } } catch (e) { console.log("响应不是合法 JSON，跳过 Token 过期检查"); }
为什么 Pre-request Script 里不能直接验证 Token 有效期
JWT 类 Token 的 exp 字段理论上可解码校验，但实际中不推荐在前置脚本里做这个判断——因为服务端可能提前吊销 Token（比如用户主动登出、密钥轮换），此时 Token 虽未过期，但已无效。仅靠客户端解码 exp 会误判。
-
jwt_decode不是 Postman 内置函数，需手动引入或用正则提取 base64 部分再atob解码，容易出错 - 即使
exp显示还有 5 分钟，服务端也可能已拒绝该 Token，最终还是要以响应结果为准 - 真正可靠的过期判断，永远发生在请求发出并收到响应之后，也就是
Tests阶段
如何让 Token 过期时自动刷新并重试原请求
Postman 没有原生“重试”机制，但可以通过 pm.sendRequest 在 Tests 中发起登录请求，拿到新 Token 后，**无法自动重发原始请求**——你得手动触发第二次发送，或把逻辑拆到 Collection 层级统一处理。
- 在登录接口的
Tests中设置：pm.environment.set("access_token", pm.response.json().token) - 在受保护接口的
Pre-request Script中读取pm.environment.get("access_token")并注入Authorization头 - 若发现过期（通过上一步的
Tests判断），需人工点击登录接口 → 更新环境变量 → 再点目标接口；自动化方案必须把登录逻辑提前到前置脚本中，且用pm.sendRequest同步阻塞式调用（注意：Postman 不支持 await，需用回调嵌套） - 更健壮的做法是：把登录请求单独做成一个 Collection，其他所有测试请求都放在另一个 Collection，并依赖环境变量；每次运行前先跑一次登录 Collection
最易被忽略的一点：Token 过期响应的判定逻辑必须和你们后端团队对齐，不能凭经验写死 code === 401。有些系统对权限不足、Token 过期、签名错误全部返回 403，区别全靠 message 字段——这个字段名、大小写、是否含空格，都得实测确认。
