这个坑我踩过不止一次最近一次是在某个压测项目里把一套 BeanShell 脚本整体迁移到 JSR223 Groovy结果第一个字符串替换就把测试数据弄得乱七八糟该替换的没换不该替换的被清空循环第二次起拿到的全是第一个请求的旧值。查到最后全是语言语义差异和脚本缓存机制在捣乱。今天就把 JSR223 和 BeanShell 切换过程中字符串替换的几个经典问题连同排查思路和标准写法一起写透。这篇文章适合正在做压测脚本迁移的性能测试工程师也适合刚接手 JMeter 脚本、想搞明白为什么别人总说“不要用 BeanShell”的新手。1. 从 BeanShell 切到 JSR223 前先看清两者的运行机制差异1.1 性能差距来自“解释执行”与“缓存编译”很多人在 JMeter 里写脚本最早接触的就是 BeanShell。它语法接近 Java上手简单网上搜出来的老教程基本都是 BeanShell。但它有一个天生的问题每次执行都要把脚本重新解释一遍没有编译缓存。在大并发压测下BeanShell 取样器会频繁触发解释器CPU 占用很快就上去了成为整个压测脚本的瓶颈。JSR223 是 Java 标准脚本接口JMeter 通过它调用 Groovy 引擎。Groovy 脚本会被编译成字节码并且 JMeter 默认缓存编译后的结果。也就是说第一次执行时编译一次后续直接跑编译好的对象省掉了反复解释的开销。在我自己的压测项目里同一段字符串加工逻辑BeanShell 跑到 100 并发时 CPU 明显爬升换到 JSR223 Groovy 之后整体稳了一大截。官方手册从 3.1 版本开始也明确推荐优先使用 JSR223原因就是性能。对比项BeanShellJSR223 Groovy执行机制每次解释执行编译后可缓存脚本缓存基本没有有效缓存默认开启编译缓存语法风格接近 JavaJava Groovy 语法糖高并发表现容易成为瓶颈更适合压测场景官方态度不推荐继续使用推荐方案1.2 同样的代码两种语言里含义可能完全不同很多人以为 BeanShell 和 Groovy 都是 Java 系的脚本语言切换就是把脚本原样复制过去。这个想法很危险。Groovy 不是“更好用的 BeanShell”它有自己的语法规则尤其是字符串处理上差别巨大。最典型的就是字符串插值。BeanShell 里写${orderId}这个双引号字符串就是普通字面量里面有什么字符就是什么字符。Groovy 里双引号字符串是 GString${orderId}会被直接替换成 orderId 变量的值。这一条就足以让大量从 BeanShell 复制过来的字符串替换代码翻车。所以切换前必须建立一个新的认知在 JSR223 里你看到的字符串不一定是运行时真正参与运算的内容。2. 字符串替换中最常见的三个具体坑2.1 替换值里出现 $ 符号正则引擎直接翻脸第一个坑发生在 replaceAll 的第二个参数上。很多人写字符串替换习惯用str.replaceAll(正则, 新值)在 BeanShell 里这么写没问题切到 JSR223 后还是这么写但如果“新值”里带了$符号结果就完全不对了。原因是 replaceAll 底层走的是正则匹配第二个参数会被当成正则的替换模板$在替换模板里是特殊字符后面跟数字表示引用第几个分组。比如替换值$1会被解释成“第一个分组匹配到的内容”如果$后面跟的不是数字或者引用的分组不存在直接抛IllegalArgumentException: Illegal group reference。实际操作中这个坑特别隐蔽。比如你从接口响应里提取了一个金额字段A$100想塞进请求体模板里def money A$100 def text 用户余额${money} def out text.replaceAll(\\$\\{money\\}, money)你以为结果会是用户余额A$100实际运行会直接报错因为$100被当成引用第 100 个分组。如果替换值恰好是$1它不会把$1作为字面文本放进结果而是把 match 到的第一组内容插入进去数据当场错乱生成出来的报文完全不是你想的那样。解决方式很简单用 Java 自带的Matcher.quoteReplacement把替换值转义一下让$回归字面含义import java.util.regex.Matcher def money A$100 def text 用户余额${money} def out text.replaceAll(\\$\\{money\\}, Matcher.quoteReplacement(money))这里还有另一个细节反斜杠\也有同样问题。如果你替换的值是 Windows 路径C:\temp\file直接塞进 replaceAll\t会被解析成制表符路径直接变样。quoteReplacement 会把\和$都处理成普通字符一套工具方法同时防两个问题。2.2 Groovy 双引号里的 ${xxx} 不是占位符是插值第二个坑专门坑从 BeanShell 嫁接过来的老代码。BeanShell 里写字符串替换双引号就是普通字符串str.replaceAll(\\$\\{orderId\\}, 20240815);在 BeanShell 里\\$\\{orderId\\}表示正则表达式\$\{orderId\}用来匹配字面量${orderId}没问题。同样一行代码搬到 JSR223 Groovy 里双引号字符串变成了 GString内部$的行为彻底改变。比如有这样一个 Groovy 脚本def orderId 20240815 def pattern \\$\\{orderId\\} def text {orderId:${orderId}} def out text.replaceAll(pattern, 20240815)这段代码里的\\$\\{orderId\\}已经不是简单的正则字符串了$后面紧跟的花括号表达到底怎么解析取决于 Groovy 的插值规则稍不留神就会变成另一个完全不同的正则。更常见的情况是有人在 Groovy 里直接写def result text.replaceAll(${orderId}, 88)这里${orderId}在双引号里会被直接替换成变量 orderId 的值比如20240815那这条替换语句实际执行的是把文本里的20240815替换成88而不是把${orderId}这个占位符替换掉。脚本没报错但结果永远是错的而且很难发现。解决方案不复杂在 JSR223 Groovy 里凡是涉及正则、占位符、替换模板这类字符串优先使用单引号字符串def pattern \\$\\{orderId\\} def replacement 20240815 def out text.replaceAll(pattern, replacement)单引号字符串在 Groovy 里就是普通的java.lang.String没有插值逻辑里面的$、{都是普通字符。如果你的字符串里还要包含单引号可以用三重单引号...它同样不做插值适合放一整段 JSON 报文模板。记住一个判断规则在 JSR223 脚本里看到双引号先停下来想一下里面的$会不会被插值。拿不准就直接用单引号这是最省事的习惯。2.3 JSR223 脚本缓存后${变量} 不刷新第三个坑是缓存机制带来的而且非常反直觉。JSR223 取样器有一个“Cache compiled script if available”的选项默认就是勾选状态。它的本意是缓存编译后的脚本提升执行效率但在字符串替换场景里它会造成一种诡异的现象脚本第一次执行正确从第二次开始替换用的值永远停在第一次的值。典型场景是这样的线程组循环 3 次每次都从登录接口提取一个新的 token然后在一个 JSR223 前置处理器里做报文替换。第一次循环token 是abc123替换结果正确第二次循环token 已经变成def456但替换出来的报文里还是abc123。问题出在脚本文本里如果直接写了${token}JMeter 在第一次执行时会把${token}替换成当时的变量值然后缓存这个编译后的脚本。后续循环里缓存直接命中不再对${token}做变量替换所以永远用的是第一次的值。官方手册对这个问题的建议非常明确在 JSR223 脚本内部不要使用 JMeter 变量占位符应该用vars.get()来获取变量。正确写法是这样的def token vars.get(token) def template {token:${token}} def payload template.replace(${token}, token ?: ) vars.put(payload, payload)这里用vars.get(token)每次执行时实时读取当前线程的变量值完全绕开脚本缓存的影响。顺便说一句BeanShell 里其实也有类似问题只是 BeanShell 没有同等强度的编译缓存很多老脚本碰巧没暴露但这不是好习惯早点改掉更稳妥。3. 切换到 JSR223 后字符串替换应该怎么写3.1 一套可以直接抄的替换写法搞清楚了坑在哪就可以写一套标准动作了。我现在的习惯是在 JSR223 脚本里写字符串替换先区分要做的是“字面量替换”还是“正则替换”然后分别对待。如果只是把模板里的占位符换成实际值最推荐用String.replace两个参数都是普通字符串第一个参数不会当成正则第二个参数里的$和\也会被自动转义。换句话说replace这个方法本身就帮我们避开了一大半坑def raw {orderId:${orderId},note:金额 $100} def orderId vars.get(orderId) ?: def result raw.replace(${orderId}, orderId)这段代码里的${orderId}是普通字符替换值即使是A$100也不会出问题。如果需要做正则替换比如要把一组匹配到的文本按某种模式重排再上 replaceAll同时用Matcher.quoteReplacement兜住替换值import java.util.regex.Matcher def raw ID_20240815_001 def result raw.replaceAll(ID_(\\d)_(\\d), $2_$1)这里替换模板$2_$1用单引号包裹意思很明确把第二组数字放到前面第一组数字放到后面。它是正则分组引用不是“从变量取值”。如果这条替换的值里混入了需要原样输出的$再单独用 quoteReplacement 处理。方法第一个参数第二个参数适用场景String.replace字面量自动安全处理占位符替换、普通字符串替换String.replaceAll正则表达式支持分组引用$ 需转义模式匹配替换、分组重排3.2 实战从响应提取值替换到下一个请求体光讲方法有点干来看一个完整的压测场景。假设有一个下单接口请求体里有两个占位符${token}和${orderId}。token 来自上一个登录接口的响应orderId 来自业务参数。在 JMeter 里先用正则提取器把 token 提取到变量token或者用 CSV 参数化把 orderId 读进变量然后在请求前挂一个 JSR223 前置处理器def template {appId:10001,token:${token},orderId:${orderId}} def token vars.get(token) def orderId vars.get(orderId) def payload template .replace(${orderId}, orderId ?: ) .replace(${token}, token ?: ) vars.put(payload, payload) log.info(最终请求体: payload)几个细节值得说明。第一模板字符串用单引号保证${token}不会被 Groovy 插值它是留给我们 later 替换用的真实占位符。第二替换顺序是先长后短比如${orderId}和${orderId2}同时存在时先替换长的否则短的先被替换掉长的也会跟着变样。第三?:是 Groovy 的判空兜底vars.get()拿不到值时不会把null拼进报文而是用空字符串顶上。这个写法在真实压测里很稳替换结果干净不依赖脚本缓存状态也不会被替换值里的特殊字符干扰。3.3 涉及正则表达式替换时保留分组引用的正确姿势有些场景必须上正则比如要从ID_20240815_001这种字符串里提取数字并重排。这时 replaceAll 的分组引用能力就很有用了。def raw ID_20240815_001 def out raw.replaceAll(ID_(\\d)_(\\d), $2_$1) // out 的结果是 001_20240815这里替换模板$2_$1里的$2、$1是正则分组引用配合单引号字符串不会被 Groovy 插值所以正确。如果你手滑用了双引号def out raw.replaceAll(ID_(\\d)_(\\d), $2_$1)Groovy 看到双引号里的$2会尝试把它当成变量插值而2不是合法变量名很容易直接报错或者得到一串奇怪的结果。这就是为什么前面反复强调单引号。还有一个容易忽略的场景替换结果本身要包含$。比如想把100替换成金额 $100直接在替换模板里写$100会被正则引擎解读为“引用第 100 组”直接报错。这时候要么把模板写成\\$100要么干脆用 replace 做字面量替换没必要非走正则不可。很多人在搬脚本时懒得区分 replace 和 replaceAll默认全部用 replaceAll这就等于把最危险的变量放进了替换模板。我的建议是反向操作默认全用 replace确实需要正则匹配时再单独挑 replaceAll并且强制在替换值上套 quoteReplacement。4. 实测问题排查与避坑技巧4.1 排查思路先看得见再去改遇到字符串替换异常我习惯的第一件事不是改代码而是把关键变量打印出来。JSR223 脚本里可以直接用log.info打印原始字符串、正则模式、替换值、替换结果四样东西log.info(替换前: raw) log.info(正则: pattern) log.info(替换值: value) log.info(替换后: result)跑一次采样器看 JMeter 的日志输出。一般能快速判断问题出在哪一层如果正则模式本身被插值了打印出来的 pattern 和你预期的完全不一样如果 pattern 对但没匹配上那就是转义层级的问题如果 pattern 对、匹配也对但抛了IllegalArgumentException那就是替换值里有$。先把现象的边界摸清楚再动手改代码比瞎试高效得多。拿到明确线索之后我还会把出错的那段脚本单独复制到一个 Groovy 环境里跑一遍。比如先准备一个假字符串固定替换值看行为是否复现。这样能把 JMeter 的变量上下文和脚本逻辑解耦更快定位是 JMeter 的问题还是脚本本身的问题。4.2 常见问题速查表这里整理了一份我在实际项目中碰到过的问题清单可以直接对照排查。现象可能原因解决方案替换没生效字符串原样输出正则转义不对模式没匹配上打印 pattern改用 replace 做字面量替换抛 IllegalArgumentException替换值里的 $ 被当成引用分组替换值套 Matcher.quoteReplacement第一次执行正确后续全用第一次的值脚本缓存 脚本里用了 ${var}改用 vars.get(var) 实时取值结果出现字符串 nullvars.get 返回 null直接做了拼接用 ?: 兜底先判空中文被替换成乱码脚本或项目的文件编码不对统一 UTF-8启动参数加 file.encodingUTF-8替换内容在不同的线程间串数据误用了 props.put 或者静态变量确认用的是 vars.putprops 是全局的改了脚本重新跑行为没变化JSR223 缓存了旧脚本重启压测进程或临时取消缓存选项这里面最容易误判的是“脚本改了没生效”。JSR223 的编译缓存会把旧脚本完整缓存住你在 GUI 里改了脚本内容不重启时不一定会执行新逻辑。排查时要先排除这个因素否则会浪费很多时间去改一个根本没在跑的脚本。4.3 几个我长期保留的脚本习惯踩过几次坑之后我现在写 JSR223 脚本基本形成了一套固定动作。第一脚本里禁止出现裸的${var}全部用vars.get(var)。这不仅是为了避开缓存问题也让脚本逻辑更清楚哪些值是从 JMeter 变量里来的一眼就能看到。第二字符串替换默认用replace。只有当我确实要写正则表达式时才会用replaceAll并且替换值一定经过Matcher.quoteReplacement包一层。第三正则模式统一用单引号字符串。Groovy 里单引号字符串不会插值这是最省心的选择。多行报文模板用三重单引号...。双引号只留给真正需要 GString 的场景或者放普通日志输出。第四压测脚本里的log.info是临时工具压测结束前记得删掉或者改成 debug 级别。大量日志输出本身也会占用 IO影响压测结果准确性。第五留意脚本文件的编码。JMeter 脚本如果保存过中文文件编码不对会导致中文占位符在正则匹配时对不上。把整个项目的文件统一成 UTF-8并在启动 JMeter 时加上编码参数能省很多莫名其妙的乱码问题。写在最后切换 BeanShell 到 JSR223不是为了换一个语法而是要换一套理解脚本运行方式的心智模型。字符串替换只是其中一个容易出问题的环节但把这块捋顺了其他脚本改造也会顺手很多。我自己现在的移植流程很简单先把脚本里的${xxx}全部改成vars.get(xxx)再把所有replaceAll改成replace除非确实需要正则最后给每个替换加上日志输出跑一次采样器确认结果。这套动作做完大部分字符串替换的坑都能绕开。剩下少部分场景是正则表达式本身写错的问题那就老老实实回到 Groovy 环境里调试用几组假数据把 pattern 验证清楚再回填到 JSR223 脚本里。希望你下次做脚本迁移时能比我省下那几个小时的查日志时间。