根本原因是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（请求发出前执行）。

• 在目标请求或其所属文件夹/集合的 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。

TokenGX Cap 验证码集成

TokenGX Cap 验证码【代码集成】技能 —— 面向开发场景，提供前端组件和后端验证的代码模板，帮助用户将 Cap 无感验证码快速集成到网站或应用中。适用场景：注册登录防刷、表单提交保护、API 接口防爬、发短信/邮件防滥用等。支持前端（HTML/React/Vue/Next.js）和后端（Node.js/Python/PHP/Go）全栈集成。触发词：集成验证码、添加人机验证、CAPTCHA 集成、cap widget、验证码前端、验证码后端、防刷表单等。与 tokengx-cap-admin（服务

下载

• 不要依赖“全局前置脚本自动续期”，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，但当前请求选的是“生产环境”，变量就为空——切环境这个动作，很多人做完登录就忘了再切回来。