根本原因是Token传了但未被识别或已失效；需检查环境变量是否正确存储与引用、Pre-request Script是否生效、服务端认证头字段是否匹配，以及环境作用域是否一致。
Postman后续接口拿不到Token，根本原因不是“没传”，而是“传了但没被识别”或“传的时候已经失效”。直接检查 Authorization 头或 X-Auth-Token 字段是否填写正确，90% 的情况下会漏掉关键链路——比如 token 没存进环境变量、前置脚本没触发、或者服务端校验逻辑压根不看那个头。
Token没存进环境变量：后续请求根本读不到
很多用户在登录接口的 Tests 里写了 pm.environment.set("token", "xxx")，但实际返回体结构是 {"data": {"access_token": "abc123"}}，而脚本里却写成 pm.environment.set("token", jsonData.token)，结果取出来是 undefined。
- 先在
Tests里加一行console.log(pm.response.text())，确认响应体真实结构 - 用
JSON.parse()解析后，逐层访问字段：比如jsonData.data?.access_token或jsonData.token，别硬猜 - 存变量时用
pm.environment.set("auth_token", value)，别拼错变量名；后续请求里必须写成{{auth_token}}，不能少花括号 - 点右上角眼睛图标查看当前环境变量值，确认它真被设进去了，且不是空字符串
Pre-request Script没生效：Token头压根没加上
即使环境变量有值，如果没在请求发送前把值塞进请求头，后续接口照样 401。常见错误是把脚本写在集合的 Tests 里（那是响应后执行），而不是 Pre-request Script（请求发出前执行）。
TokenGX Cap 验证码【代码集成】技能 —— 面向开发场景，提供前端组件和后端验证的代码模板，帮助用户将 Cap 无感验证码快速集成到网站或应用中。适用场景：注册登录防刷、表单提交保护、API 接口防爬、发短信/邮件防滥用等。支持前端（HTML/React/Vue/Next.js）和后端（Node.js/Python/PHP/Go）全栈集成。触发词：集成验证码、添加人机验证、CAPTCHA 集成、cap widget、验证码前端、验证码后端、防刷表单等。与 tokengx-cap-admin（服务
- 在目标请求或其所属文件夹/集合的
Pre-request Script标签页里写： const token = pm.environment.get("auth_token");if (token) { pm.request.headers.add({key: "Authorization", value: "Bearer " + token}); }- 注意：如果后端用的是
X-Auth-Token，就别硬套Authorization；查服务端文档或日志确认期望的 header key - 脚本里加
console.log("Using token:", token)，发请求时打开 Postman Console（View → Show Postman Console）看有没有输出
Token已过期但没自动刷新：401 错误反复出现
Token 过期后，单纯重跑登录接口并手动复制粘贴不可持续。真正的解法是让 Postman 在遇到 401 时自动重登录——但这需要你在每个受保护接口的 Tests 里做状态判断，并触发 pm.sendRequest。
- 不要依赖“全局前置脚本自动续期”，Postman 不支持运行时中断当前请求去换 token 再重发
- 在功能接口的
Tests中检查响应码：if (pm.response.code === 401) { /* 调用 login 接口 */ } -
pm.sendRequest是异步的，无法阻塞当前请求；所以更稳妥的做法是：把登录请求单独建一个文件夹，每次测试前先点一次，再切回功能请求 - 若必须自动，需确保 login 接口本身不依赖 token（通常要加
isToken: false到 header），否则会陷入死循环
服务端校验逻辑和你填的位置不匹配
你填了 Authorization: Bearer xxx，但服务端只认 X-Auth-Token: xxx，或者要求 token 放 query 参数里（如 ?token=xxx），甚至要从 Cookie 里读 SESSIONID。这种错位不会报错格式问题，只会稳定返回 401。
- 看响应头里的
WWW-Authenticate字段，例如WWW-Authenticate: Bearer realm="api.example.com"，这说明它明确要 Bearer 方案 - 翻后端代码或 Swagger 文档，确认认证方式（JWT/OAuth2/Session/Cookie）和传输位置
- 用 curl 对比验证：把 Postman 生成的 curl 命令复制出来，手动改 header 或参数再试一次，排除 Postman 界面干扰
- 如果服务端用了 Nginx 或网关，检查它是否过滤/重写了 header（比如删掉了
Authorization）
最常被忽略的一点：环境变量作用域。你在“测试环境”里设了 auth_token，但当前请求选的是“生产环境”，变量就为空——切环境这个动作，很多人做完登录就忘了再切回来。
