JMeter避坑：Token写死还是动态获取？

哈喽，宝子们，今天我们不聊AI，聊个接口测试新手必踩的坑：Token。

你是不是也干过：浏览器登录系统，按 F12，找到登录接口返回的 Token，复制，粘贴到 JMeter 的 HTTP 信息头管理器里。点击运行，接口绿了。你心里想：JMeter 也不难嘛。

结果第二天再跑，全部 401。

其实不是 JMeter 坏了，是 Token 过期了。

先把结论放这：

临时调试可以写死，正式脚本必须动态获取。

下面用商城项目的案例，把这件事讲清楚。

一、Token 到底是什么？

Token 就是登录通行证。你登录后服务器发一个临时凭证，后续所有查数据、做业务的接口都要带着它，服务器才认你。

关键事实： Token 有有效期。

不同系统不一样，可能几分钟、几小时甚至几天，具体看服务端。过期后通常会返回 401，也可能根据系统设计返回其他错误码。重新登录通常会生成新 Token。

所以写死 Token 的脚本，天生不稳定。

二、写死 Token：什么时候行，什么时候不行？

新手爱写死 Token，因为快。刚学 JMeter 的时候，目标只有一个：先让接口跑通。

写死 Token 的优点很直接：

• 不用理解关联；
• 不用配 JSON 提取器；
• 不用管作用域；
• 复制粘贴就能跑。
  
  

下面这些场景，写死 Token 可以接受：

一句话： 写死 Token 只能让你跑通一次，不能让你跑通一百次。

三、写死 Token 的三次翻车

案例 1：隔夜就失效，脚本全红

做商城项目时，第一天用 F12 复制了 Token，跑通了“查询订单”接口。脚本保存，下班。

第二天早上，打开 JMeter，直接运行。

结果：

   
   
   
   401 Unauthorized

检查了半天请求地址、参数、请求头，最后发现：Token 过期了。

这就是最常见的坑：昨天的 Token，今天不一定还能用。

案例 2：接口字段一改，全脚本崩

后来学聪明了，把 Token 写到了“用户变量”里。但没过几天，开发把登录接口返回值改了：

以前：

   
   
   
   {"token":"abc123"}

现在：

   
   
   
   {"data":{"accessToken":"abc123"}}

脚本又挂了。因为写死的不仅是 Token 值，还依赖了旧字段。

如果是动态提取，只需要改一下 JSON Path，其他接口不用动。

案例 3：并发压测，10 个人查到同一个订单

再做压测时，心想：Token 写死也能跑，反正都是登录用户。

结果 10 个线程并发，每个线程都用同一个 Token。服务端一看：怎么同一个用户同时查了 10 次订单？

如果系统有风控，直接限流；如果数据隔离不严，可能查到同一个人的数据。压测结果完全不可信。

写死 Token，本质上只有一个用户。动态获取，才可能模拟多个真实用户。

四、动态获取：让 JMeter 自己拿 Token

还是用商城项目。

登录接口返回：

   
   
   
   {"code":0,"data":{"token":"abc123"}}

目标：JMeter 先登录，自动拿到 abc123 ，后面所有接口都带着它。

第 1 步：添加登录请求

线程组下添加：

   
   
   
   HTTP 请求：POST /login

请求体：

   
   
   
   {"username":"testuser","password":"123456"}

第 2 步：在登录请求下加 JSON 提取器

右键登录请求 → 添加 → 后置处理器 → JSON 提取器。

配置：

   
   
   
   Names of created variables: tokenJSON Path Expressions: $.data.tokenMatch No.: 1Default Value: TOKEN_NOT_FOUND

意思是：从响应 JSON 里找 data.token ，存到变量 token 里。

第 3 步：在需要鉴权的请求下加 HTTP 信息头管理器

配置：

   
   
   
   名称：Authorization值：Bearer ${token}

注意：如果登录返回的 Token 已经带了 Bearer ，这里就直接写 ${token} ，不要重复拼。

第 4 步：加 Debug Sampler 验证

运行后看 Debug Sampler，如果看到：

   
   
   
   token=abc123

说明提取成功。

如果看到：

   
   
   
   token=TOKEN_NOT_FOUND

说明 JSON Path 写错了，或者作用域放错了。

五、动态获取后最容易踩的三个坑

坑 1：作用域放错

HTTP 信息头管理器如果直接放在线程组下，会影响线程组里所有请求，包括登录请求。

更稳的做法：

   
   
   
   线程组├── 登录请求│   └── JSON 提取器└── 简单控制器：需要鉴权的接口    ├── HTTP 信息头管理器    ├── 查询订单    └── 添加购物车

这样 Token 只作用于需要鉴权的接口，不会干扰登录。

坑 2：Bearer 重复或漏拼

常见错误：

   
   
   
   Authorization: Bearer Bearer abc123

或者：

   
   
   
   Authorization: abc123

正确做法：

• 提取时只提 Token 本身；
• 请求头里拼 Bearer ${token} ；
• 如果响应里已经带 Bearer ，就直接用 ${token} 。

坑 3：多用户和跨线程组混用

vars 是线程内变量， props 是全局属性。

跨线程组可以这样：

登录线程组：

   
   
   
   props.put("token", vars.get("token"));

其他线程组请求头：

   
   
   
   Bearer ${__P(token)}

但注意： 多用户并发时不要用全局 props。 因为多个线程会互相覆盖 Token。

多用户压测应该用 CSV 参数化：

   
   
   
   username,passworduser1,123456user2,123456user3,123456

每个线程取一组账号密码，自己登录，自己拿 Token。这样每个线程的 vars 是独立的，不会串。

六、再进阶：Token 过期、多用户和 CI

Token 过期怎么办？

功能测试可以用 Once Only Controller ，让每个线程只登录一次。

   
   
   
   线程组└── Once Only Controller    └── 登录请求

但注意：它只能保证每个线程只登录一次，不能解决长时间压测中 Token 过期的问题。如果长时间压测 Token 会过期，最好让开发提供长效测试 Token，或者测试白名单。JMeter 里做 401 自动刷新不是不行，但复杂度高，新手别一上来就硬刚。

多用户压测怎么做？

用 CSV 参数化账号密码，每个线程自己登录，自己拿 Token。不要用全局 props 共享 Token。

脚本进 Jenkins 要注意什么？

• 环境地址要参数化；
• 账号密码不要写死，从 CSV 或环境变量读取；
• Token 必须动态获取；
• 每次构建先登录，再跑业务接口。

结尾：Token 写死还是动态获取？

我的建议很简单：

临时调试可以写死，正式脚本必须动态。

写死 Token，能让你跑通一次；动态获取 Token，才能让你重复跑、换环境跑、多用户跑、上 CI 跑。

别让一个复制粘贴的 Token，成为你 JMeter 路上的第一个大坑。

话题讨论：

讨论1：你第一次被 Token 坑，是 401 还是 403？

讨论2：多用户压测时，Token 应该共享还是每个线程独立登录？

讨论3：功能测试用 Once Only Controller 够不够？长时间压测是让开发给长效 Token，还是让 JMeter 自己处理 401 自动刷新？

以上话题，任选其一，欢迎评论区留言。小编会在下下周一（2026 年 10 月19 日）下午，选取 1 位“关注+点赞+留言”的幸运用户，送出《Web 安全测试技术详解》1 本，快来评论区互动吧~