压测中正则定义的Access Token仅20%调用传对，26%请求因未传Token值报错

结合你观测到的“26%错误率、失败请求仅携带Access Token参数名、无实际Token值、仅20%的请求能正常传递Token”的现象，问题基本不会出在业务接口本身，基本都是关联提取的全链路配置错位导致的，可按以下优先级逐一核对：

• 正则提取器的挂载位置与时序配置错误
  正则提取器是后置处理器，只会在它所挂载的那个取样器执行完成后才触发。如果提取器没有直接挂在登录请求取样器的子节点下，而是挂在线程组、事务控制器这类父层级节点上，就会出现执行时序错位：部分用户还没完成登录、没拿到登录响应的时候，提取器已经提前触发，自然抓不到任何Token；部分用户走完登录流程后提取器才正常触发，就能拿到有效值，最终就会出现这种部分成功、部分全空的传递结果。
  另外要核对提取器的「应用范围」配置：如果选了“主样本和子样本”模式，而登录响应里带了很多嵌入式资源、第三方关联请求的返回内容，正则规则可能误匹配到空值、或者直接找错了Token的所在位置，输出空的提取结果。
• 正则规则的适配性不足，导致部分响应提取失败
  你提到有20%的请求能正常拿到Token，说明正则的核心匹配逻辑是对的，但兼容性不够：
  • 写规则的时候没用非贪婪匹配，遇到带换行、额外空格、字段顺序微调的响应时，就会匹配失败返回空值
  • 规则没覆盖响应里可能出现的格式差异，比如Token字段和分隔冒号之间多了一个空格，原规则就根本命不中目标内容
• 并发场景下的变量写覆盖问题
  不少人为了少写配置，会把提取到的Token通过__setProperty函数设成全局属性，而不用JMeter默认的线程私有变量存Token，这在并发场景下必出问题：100个并发用户都会往同一个全局属性里写自己的Token值，一旦某个用户提取到了空值，就会把这个属性直接更新成空；其他用户引用这个被覆盖的属性值时，自然就拿到空值，发出去的请求也就只剩参数名了。
• JMeter变量引用的默认行为放大了空值问题
  JMeter有个很容易踩的默认逻辑：如果引用的变量不存在、或者值为空，脚本不会直接抛错中断，只会悄无声息把参数值留空。比如你在业务请求里配的Token参数值是${access_token}，一旦这个关联变量没被成功赋值，最后发出去的请求里就只有access_token=这么一段，也就是刚好只有参数名、没有实际值，和你看到的失败现象完全对得上。

快速定位的小技巧：

• 在所有引用Token的业务请求前加个调试取样器，运行的时候直接看实际提取到的access_token是多少，就能快速判断是提取环节空了，还是传递环节被并发逻辑覆盖了
• 给正则提取器设个明确的默认值，比如把默认值填成TOKEN_MISS，如果后续请求里出现的参数值就是这个字符串，就能100%确定是提取环节没拿到有效值

内容的提问来源于stack exchange，提问作者Pasa