Postman中需用Tests脚本提取Token并存入环境变量：JSON响应用pm.environment.set("token", pm.response.json().data.token)，响应头用pm.environment.set("token", pm.response.headers.get("X-Auth-Token"))，须加if (pm.response.code === 200)校验状态码，且仅支持pm.environment.set()或pm.globals.set()，后续请求通过{{token}}引用。
Postman里怎么用Tests脚本提取Token
登录接口返回的token通常在响应体（JSON）或响应头（如Authorization、X-Auth-Token）里，Postman本身不自动保存，必须靠Tests脚本手动提取并写入环境变量。不写脚本，后续请求就无法复用这个token。
常见错误是直接在Tests里用console.log()看值，但没调用pm.environment.set()或pm.globals.set()——这等于白提。
- 如果返回的是JSON，比如
{"code":0,"data":{"token":"abc123"}}，用pm.environment.set("token", pm.response.json().data.token) - 如果
token在响应头里（比如X-Auth-Token: abc123），用pm.environment.set("token", pm.response.headers.get("X-Auth-Token")) - 注意检查响应状态码是否为
200再提取，避免登录失败时覆盖掉有效的token：加个if (pm.response.code === 200) { ... }
为什么用pm.environment.set而不是pm.variables.set
pm.variables.set()根本不存在——这是新手常搜错的API。Postman只支持pm.environment.set()（存到当前环境）和pm.globals.set()（存到全局变量）。选哪个取决于你的使用场景：
- 多环境切换（dev/staging/prod）时，用
pm.environment.set()，避免不同环境的token互相污染 - 临时调试、单接口快速验证，用
pm.globals.set()更省事 - 无论哪种，后续请求的
Authorization字段都要写成{{token}}，Postman会自动替换
登录后Token没生效？检查这三点
写了脚本、也看到环境变量里有值，但后续请求还是401，大概率卡在这几个地方：
- 请求头没正确引用变量：比如写了
Authorization: Bearer {{token}}，但实际接口要求的是Authorization: Token {{token}}或X-Token: {{token}}，格式必须和后端文档一致 - 环境没选对：右上角环境选择器（下拉框）是否已切换到你写入
token的那个环境？选No environment时所有{{xxx}}都会为空 - 响应内容类型不是
application/json：比如后端返回text/plain，pm.response.json()会直接报错中断脚本，需要先判断pm.response.headers.get("Content-Type")是否含json，否则改用pm.response.text()配合JSON.parse()
Token过期了怎么自动刷新
Postman没有内置的“自动重登录”机制。如果token过期导致后续请求返回401，不能指望它自己调登录接口——得靠前置脚本（Pre-request Script）做兜底检查：
- 在每个需鉴权的请求前，加一段脚本：读取当前
{{token}}，发一个轻量接口（如/api/v1/user/profile）校验有效性；若返回401，再触发一次登录请求，并更新token - 更稳妥的做法是把登录逻辑封装成独立请求，用
pm.sendRequest()在Pre-request Script里调用，但要注意避免死循环（比如登录接口自己也依赖token） - 简单项目建议手动点一下登录请求更新即可；高频迭代或CI集成时，才值得投入写自动刷新逻辑
真正麻烦的不是提取，而是Token生命周期管理——有效期、刷新机制、多终端互踢这些，Postman只负责搬运，背后的业务规则得你自己对齐。
