Postman中Token必须用环境变量管理，登录响应提取后通过Tests脚本存入pm.environment.set，并在Headers中用Bearer {{access_token}}引用；避免硬编码、Pre-request自动刷新及变量作用域错误。

Postman里Token必须用变量管理，硬编码或手动复制粘贴一定会出错——尤其是当Token 5分钟失效、环境切换频繁、或多个团队成员共用同一套集合时。直接写死Authorization头或在每个请求里填字符串，等于把自动化测试退化成手工点单。

登录响应里提取Token并存入环境变量

这是最常用也最稳妥的做法：让登录接口的Tests脚本自动解析响应、提取Token、写入环境变量。

• 确保登录接口返回结构清晰，比如{"token": "eyJhbGciOi..."}或{"data": {"access_token": "..."}}
• 在该请求的Tests标签页中写脚本，别写在Pre-request Script（那是发请求前跑的）
• 用pm.environment.set("access_token", token)，不是pm.globals.set——除非你真需要跨所有环境复用同一个Token（通常不该这样）
• 加一层判空和类型检查，避免undefined写进变量：

  const res = pm.response.json();
  const token = res.token || res.data?.access_token;
  if (token && typeof token === 'string') {
    pm.environment.set("access_token", token);
  } else {
    console.error('Failed to extract token from response');
  }

在请求头中引用Token变量的两种写法

不是所有地方都能直接写{{access_token}}，得看上下文是否支持变量解析。

TokenGX Cap 验证码集成

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

下载

• 在Headers选项卡里，Key填Authorization，Value填Bearer {{access_token}}——这是最常见且兼容性最好的方式
• 在Authorization选项卡里，选Bearer Token类型，然后在Token输入框填{{access_token}}——这个写法更语义化，但某些老版本Postman对变量解析有延迟，建议优先用Header方式
• 如果Token需放在自定义头（如X-Auth-Token），只能走Headers选项卡，不能依赖Authorization面板
• 千万别在Body或URL参数里裸写{{access_token}}而不校验——一旦变量为空，请求会发出去但带无效值，后端可能返回401或403，你却以为是逻辑问题

Pre-request Script里自动补Token的风险点

有人想“一步到位”，在目标请求的Pre-request Script里调用pm.sendRequest去刷Token。这看似省事，实则埋雷。

• pm.sendRequest是异步的，脚本不会等它完成才发主请求——大概率主请求带着旧/空Token发出
• 没有错误兜底：如果登录接口超时或返回500，access_token变量不会被更新，后续请求仍用过期值，但控制台可能只报TypeError: Cannot read property 'access_token' of undefined，不直观
• 调试困难：你没法在Console里直接看到pm.sendRequest的响应体，得靠console.log(res.json())手动打点
• 真正需要自动刷新的场景（如OAuth2 refresh_token流程），应单独建一个“Refresh Token”请求，由人手触发，而非耦合进每个业务请求

Secret标记和变量作用域混淆是高频翻车现场

很多人设了access_token变量，却在右上角环境选择器里没选中对应环境——结果{{access_token}}始终解析为空，还反复检查脚本有没有写错。

• 务必勾选环境变量的Secret复选框，否则Token明文显示在界面上，截图或录屏时极易泄露
• 变量名别用token这种泛称，统一用access_token或auth_token，避免和全局变量token、集合变量token冲突（Postman按Local > Environment > Global优先级覆盖）
• 检查变量是否生效：点击右上角眼睛图标，确认access_token出现在当前激活环境的Current values里，且值非空
• 如果用了pm.environment.set但Current values没变，大概率是脚本没执行（比如登录请求没点Send），或者脚本里有语法错误被静默吞掉（打开Console看报错）

Token变量化的本质不是“让Postman记住一个字符串”，而是建立一套可验证、可审计、可隔离的凭据流转链。环境没选对、Secret没勾、变量名冲突、脚本位置放错——这些细节比语法本身更容易导致失败。