干了这么多年接口测试，我见过太多人把 JMeter 当“小白工具”用：打开函数助手，找个__time，复制进去，完事。等到真要造数据、做参数化、跨线程组传 token、在性能测试里模拟真实用户分布的时候，才发现函数这一块根本绕不过去。JMeter 内置函数看着一大堆，实际高频使用的也就那二三十个。把它们的执行逻辑和适用场景搞清楚，接口测试和性能测试都能省下一大半时间。
这篇文章不讲虚的，直接把你日常遇到最多的函数按场景拆开：随机数据怎么造、时间戳怎么生成、CSV 怎么读、属性怎么跨线程传、断言里怎么合理用函数、压测时哪些函数不能乱用。新手可以把这篇当速查手册，已经做了几年测试的人，也能从这里面找到几个平时容易忽略的坑。
1. 先搞懂 JMeter 函数的执行逻辑，比背函数名重要
1.1 函数到底是什么，和变量有什么区别
很多新人把${var}和${__time()}混着用，以为是一个东西。实际上 JMeter 变量是一个已经存在的值，是提前被定义好的；而函数是运行时动态计算出来的。${__time()}每次执行到的时候都会重新取当前时间，这就决定了它天然适合做动态参数。
函数的标准格式是${__函数名(参数1,参数2,...)}，注意函数名前面是双下划线。使用函数助手生成的时候，JMeter 会自动带上双下划线和花括号，你只需要填参数。这里有个容易翻车的细节：如果你在参数里要放一个包含逗号的值，直接写会导致函数解析出错。JMeter 提供了__escapeCommas函数，或者你也可以在参数里用\,转义。类似这种小细节，官方文档里写得迷迷糊糊，实际踩过一次就记住了。
还有一个常见的误区是“函数到底什么时候被求值”。JMeter 脚本的请求参数、断言、后置处理器中，函数通常是在“使用到这个参数”的时候才被求值，所以绝大多数情况下每次请求都会重新计算。但如果你把函数写在某个配置元件的初始化参数里，比如 CSV Data Set Config 的文件路径，那它可能只在线程组启动时计算一次。这个差异恰好能解释很多“为什么我的时间戳不更新”的诡异问题。
1.2 三种常见调用方式，你至少得会前两种
第一种是直接在测试元素里手写。比如请求参数的值写${__time(yyyy-MM-dd HH:mm:ss,)}，JMeter 在执行到该取样器时会自动计算并替换。
第二种是用函数助手对话框生成。打开方式：菜单栏Options -> Function Helper Dialog，或者快捷键Ctrl+Shift+F1。在对话框里选择函数、填写参数、点击生成，然后把生成的字符串复制到目标位置。这种方式最大的好处是不会拼错函数名和参数顺序。
第三种是在 JSR223 或 BeanShell 脚本里通过 API 调用。比如在 Groovy 脚本里用vars.get("token")读取变量，用props.put("key", value)设置属性。很多人在脚本里写${var}直接引用变量，这在小场景下能跑，但在 JSR223 里遇到脚本缓存或特殊上下文时会得出奇怪的结果，后面章节我会专门讲。
1.3 变量、属性、函数三者怎么配合
把这三个概念理清楚，参数化和数据关联基本就学会了一半。
变量（JMeter Variables）是当前线程局部可见的，比如正则表达式提取器提取出来的 token 存在变量里，只能在这个线程的后续取样器里引用。属性（JMeter Properties）是整个 JMeter 进程全局可见的，可以跨线程组、跨线程传递。函数则是“动态求值”的手段，可以在任何需要动态值的地方执行。
举个经典场景：登录线程组 A 获取 token，业务线程组 B 需要使用这个 token。直接用变量传递是不行的，因为变量是线程隔离的。正确做法是在 A 线程组的后置处理器里用props.put("token", token)把 token 存为 JMeter 属性，然后在 B 线程组用${__P(token,)}读取。后面第 3 章会详细展开，这里先记住结论：跨线程传值用属性，不用变量。
2. 数据动态化必杀技：随机数、时间、UUID 这类函数怎么用
2.1__Random和__RandomString：造数据的万能钥匙
__Random生成随机整数，常见写法${__Random(100000,999999,)}，表示生成 100000 到 999999 之间的随机数。注册接口测试时造手机号，就可以用固定号段加随机数拼接：138${__Random(10000000,99999999,)}。
这里有一个真实踩过的坑：如果接口对字段长度有严格要求，比如后 8 位必须是 8 位数字，直接用__Random(0,99999999)可能生成12345这种不足 8 位的数字，字符串拼接后变成13812345，位数不对导致接口校验失败。正确做法是用__RandomString(8,0123456789,)生成固定长度的随机数字字符串，保证永远是 8 位。这个函数第二个参数是字符集，长度不够时字符会重复选取，所以生成结果是允许重复的，如果要保证唯一，得配合时间戳或者计数函数。
__RandomString的更多玩法：生成固定长度的小写字母、字母数字混合字符串，最典型的是订单号、用户名、优惠券码。比如${__RandomString(16,abcdef0123456789,)}生成 16 位随机字符串。第三个参数是可选变量名，比如${__Random(1,100,randNum)}会把结果存到randNum变量里，后续可以用${randNum}引用。但大多数场景直接使用返回值就够了，没必要多一层变量转换。
2.2__time和__timeShift：时间戳的正确生成方式
时间函数几乎是每个接口都会用到的。最常见的三个形态：
${__time(yyyy-MM-dd HH:mm:ss,)}：返回格式化的当前时间${__time(,)}：返回毫秒级时间戳${__time(/1000,)}：返回秒级时间戳
第三种的/1000表示对时间戳做除法运算，这是 JMeter 函数里少见的“数学简写”，很多人第一次看到会懵。如果你需要的是“明天这个时间”“昨天 0 点”“五分钟后”，就要用__timeShift。
__timeShift的典型写法是${__timeShift(yyyy-MM-dd HH:mm:ss,,P1D,,)}：第一个参数是输出格式，第二个参数留空表示基于当前时间，第三个参数P1D表示加一天，P-2H表示减两小时，PT30M表示加 30 分钟。这是 ISO-8601 的周期格式，熟悉之后非常强大。做优惠券过期时间、活动开始时间、签名接口的有效期判断时，这个函数能省掉一大堆手动计算。
需要特别提醒时区问题：__time默认使用 JMeter 所在机器的本地时区。如果你在本地 Windows 上调试没问题，但压测机是 UTC 时区的服务器，生成出来的时间字符串可能和业务接口对不上。签名接口尤其敏感，时间戳对不上直接验签失败。我见过不止一次线上压测因为时区字段差 8 个小时排查了半天，后来发现是压测机时区问题。
2.3 高频函数速查表：UUID、threadNum、iterationNum、counter
| 函数/变量 | 写法示例 | 作用 | 典型场景 |
|---|---|---|---|
| UUID | ${__UUID()} | 生成全局唯一标识 | 请求唯一 ID、订单号 |
| 当前线程号 | ${__threadNum} | 当前线程编号，从 1 开始 | 日志区分线程、拼唯一数据 |
| 当前迭代数 | ${__iterationNum} | 当前线程已执行的迭代次数 | 循环场景下生成序号 |
| 计数器 | ${__counter(TRUE,)} | 全局或线程独立的计数 | 顺序编号、批量造数据 |
| 机器名 | ${__machineName} | 当前机器名称 | 分布式压测识别来源 |
| JMeter 版本 | ${__jmeterVersion} | 当前 JMeter 版本号 | 调试脚本时输出环境信息 |
这里要特别说明：__threadNum和__iterationNum严格来说不是函数助手里的“函数”，而是 JMeter 内置变量，直接写${__threadNum}就能用，不需要加括号。__counter的第一个参数TRUE表示所有线程共享计数，也就是全局编号 1、2、3 一直往上加；FALSE表示每个线程独立计数，每个线程都从 1 开始。这两种模式在性能测试造数据时差异很大，选错会导致数据编号混乱。
__threadNum有一个隐藏用途：在压测时把${__time(yyyyMMddHHmmss)}_${__threadNum}拼进请求体，可以快速定位日志或者按线程区分数据，非常实用。
3. 把文件里的数据搬进脚本：CSV 读取和属性传递实战
3.1 CSV Data Set Config 和__CSVRead，到底选哪个
参数化最常用的其实是 CSV Data Set Config 配置元件，它不是函数，而是一个完整的配置组件。按迭代逐行读取文件，支持多线程安全、支持分隔符自定义、支持一次性加载或按需读取。而__CSVRead(file,columnIndex)是一个函数，按“列索引”读取指定文件中的值，适合临时用一下、不想创建配置元件的场景。
我的习惯是：正式压测一定用 CSV Data Set Config，因为它对并发线程的数据分配更可控，支持“共享模式”的选择；调试一次性接口时才图省事用__CSVRead。
CSV Data Set Config 的几个容易踩的坑：文件带表头时要勾选“忽略首行”，变量名用逗号分隔；文件编码是 UTF-8 还是 GBK 要看数据源，中文乱码通常都是编码不一致导致的；共享模式的设置决定了数据是“所有线程共享一份、依次取”还是“每个线程独立取一份”。如果压测目标是模拟不同用户，建议选择“当前线程组”，保证每个线程取到的数据不重复。
3.2__StringFromFile：免配置元件的随机文件读取
${__StringFromFile(data.txt,,,)}每次调用会从文件中随机返回一行内容。适合读取字典类数据，比如随机取一个城市、随机取一个姓氏。但它的机制是“随机读取”，不是顺序读取，如果业务上需要数据按顺序分配，就不能用这个函数。
如果需要顺序读取，可以配合计数器指定起止行：${__StringFromFile(data.txt,${__counter(FALSE,)},${__counter(FALSE,)})}。不过这种写法在多线程场景下容易出问题，文件读取的位置指针是共享的，不同线程之间会互相干扰。我的建议是：少量数据用__StringFromFile没问题，大型压测还是回归 CSV Data Set Config 或者提前把数据生成到内存变量池里。
3.3 属性传递函数：__P、__property、__setProperty的正确用法
这部分内容面试常考、实战常用。JMeter 线程组之间变量不共享，登录线程组拿到的 token，业务线程组默认是看不到的。解决方案就是 JMeter 属性。
具体步骤：
- 在登录请求的后置处理器（JSR223 PostProcessor）里写：
props.put("token", vars.get("token")) - 在业务线程组需要用到 token 的地方写成：
${__P(token,)}
用函数实现就是${__setProperty(token,${token},)}。这种写法能跑，但缺点是把设置属性的逻辑写在了参数里，一眼看上去非常绕，而且变量嵌套容易出错。我更推荐在 JSR223 脚本里用props.put，逻辑清晰、好排查、还能在脚本里做空值判断。
__P还有一个杀手级用途：命令行传参。压测的时候你想动态切换被测环境地址，可以在脚本里把 host 写成${__P(host,10.0.0.1)}，然后用命令行执行jmeter -Jhost=test.example.com -n -t script.jmx -l result.jtl。这样同一个脚本不用改任何内容，就能在多个环境间切换，非常方便。这也是 JMeter 属性比硬编码参数高级的地方。
4. 字符串拼接和脚本断言的函数取舍，别把逻辑写成黑魔法
4.1 字符串拼接的正确姿势：什么情况用__V
很多人习惯直接用${a}-${b}做字符串拼接，简单场景确实没问题。但一旦涉及“变量名本身是动态的”，普通拼接就失效了。举个例子：你想根据循环次数取不同的用户变量，变量名分别是user_1、user_2、user_3。如果直接写${user_${__counter(FALSE,)}}，JMeter 会尝试解析一个名为user_的变量，结果大概率是空值。
正确写法是${__V(user_${__counter(FALSE,)})}。__V函数的作用是：把参数当成一个“变量名的字符串”，先解析出变量名，再去找这个变量名对应的值。相当于“变量的变量”。这个函数在数据驱动、循环取数、多条件组合的场景下非常关键，强烈建议记住。
4.2__eval、__groovy、__javaScript辨析
这三个函数容易混淆，但实际场景差别很大。
__eval的作用是解析参数中的变量引用并返回结果。比如${__eval(${var1}${var2})}会先把var1和var2替换成具体值再拼接返回。它适合简单的“先组合再取值”场景。
__groovy允许你在函数里直接写 Groovy 表达式，比如${__groovy(new Date().format('yyyy-MM-dd'))}，也可以做复杂的字符串处理和计算。功能很强大，但要注意：在请求参数里高频使用__groovy会有性能开销，因为它每次调用都要解释执行。压测脚本里不建议在超高频请求中用这个，更适合在初始化阶段或低频业务中使用。
__javaScript是 JavaScript 引擎实现，性能和能用的 API 都有限。这里要特别提醒一个容易踩的坑：不要在这个函数里写箭头函数，例如${__javaScript((x) => x + 1)}。底层 JavaScript 引擎版本较老，箭头函数的语法很可能不被支持，直接报错。看到报错先别怀疑是 JMeter 版本问题，大概率是语法太新。能用__groovy解决的事情，就别去折腾__javaScript。
4.3 断言里怎么合理使用函数和脚本，重点解析 Beanshell 断言
很多老教程还在教 BeanShell 断言，它确实能用，但性能差，JMeter 官方也一直建议优先用 JSR223 + Groovy。在 BeanShell 断言里，引用变量要用vars.get("xxx")，而不是${xxx}直接嵌入。响应判断用prev.getResponseCode()、prev.getResponseDataAsString()。
举个例子，下面这段 BeanShell 断言判断接口返回码和关键字段：
String resp = prev.getResponseDataAsString(); String code = prev.getResponseCode(); if (code.equals("200") && resp.contains("\"success\":true")) { Failure = false; } else { Failure = true; FailureMessage = "断言失败，响应码：" + code + "，响应体：" + resp; }如果接口返回的是 GBK 编码，getResponseDataAsString()可能会乱码，可以改成new String(prev.getResponseData(), "UTF-8")强制指定编码。
但是我的建议是：新脚本一律用 JSR223 + Groovy，别再用 BeanShell 了。BeanShell 的问题不止是性能差，还有脚本编译不稳定、语法限制多。Groovy 的写法更接近 Java，又能直接操作prev、vars、props、log这些 JMeter 上下文对象。
一个典型的 Groovy 断言：
def resp = prev.getResponseDataAsString() def json = new groovy.json.JsonSlurper().parseText(resp) if (json.code != 0) { AssertionResult.setFailure(true) AssertionResult.setFailureMessage("接口返回错误 code：" + json.code + "，message：" + json.message) }这里的AssertionResult可以直接操作断言结果，比 BeanShell 的Failure/FailureMessage字段更直观。而且 Groovy 有内置的 JSON 解析库，在断言里校验嵌套字段非常舒服。
5. 性能测试场景里函数的正确用法
5.1 压测数据分布：随机函数不是用得越多越好
性能压测最怕的是“所有线程请求同一个数据”。所有用户都在登录同一个账号、所有订单都是同一个 ID，服务端缓存一命中，压出来的结果和真实业务差了十万八千里。用__Random生成动态参数能解决一部分问题，但要注意分布是否合理。真实用户场景里，用户 ID 往往是连续或分段分布的，直接全随机可能不符合业务模型。
更可靠的方案是准备一份真实脱敏数据，用 CSV Data Set Config 按线程组驱动。这样既保证了数据不重复、又可预期、分布可控，压测结论才敢写到报告里。随机函数在性能测试里更适合用在“不那么要求真实分布”的字段上，比如时间戳、请求唯一 ID、随机金额。如果要在压测脚本里混用随机数和固定数据，推荐用“CSV 提供主体数据 + 随机函数生成补充字段”的组合。
5.2 压测时如何查看接口响应内容，以及时间戳的妙用
压测过程中如果想实时查看接口返回，不要在 GUI 模式下跑大规模压测，GUI 模式本身会消耗大量资源，压测结果也不可信。正确做法是使用命令行执行，然后在脚本中增加“保存响应数据”的配置。JMeter 5.6.3 之后生成测试报告的命令通常是：
jmeter -n -t script.jmx -l result.jtl -e -o report_dir如果你只关心某个接口的响应内容，可以在取样器上添加断言，并把“将断言失败响应数据保存到日志”开启。这样只有异常请求会落盘，日志量小、问题定位快。
还有一种做法：在请求体里拼入${__time(yyyyMMddHHmmss)}_${__threadNum}作为请求唯一标识。当业务方问“为什么这个用户产生了两笔订单”时，你只要查日志里这个标识，就能立刻定位是哪个线程在什么时间发的请求。这个技巧在排查接口幂等性问题时特别好用。
5.3 高并发下函数使用注意事项：性能杀手要避开
高并发场景下，函数调用本身也有开销。Beanshell 断言是最大的性能杀手，每个请求进来都要解释执行一次脚本，压测机 CPU 很容易被打满。__javaScript、__groovy如果写在高频请求的参数里，同样会有额外开销。
能用 CSV 预生成数据就少用随机函数，能用 JSR223 + Groovy 并且勾选“Cache compiled script”就少用 BeanShell。关于脚本缓存，多说一句：JSR223 取样器/后置处理器属性里有一个“缓存编译脚本”的选项，勾选后脚本只编译一次，后续直接执行，性能差距很大。但要注意：勾选了缓存之后，脚本里的变量是在首次编译时捕获还是每次执行时读取，行为会有差异，所以脚本里访问变量一定要通过vars.get()，不要直接外嵌${var}。
还有一个隐藏坑：__Random在高并发下偶发重复，原因是并发场景下随机数种子的初始化时序问题。如果业务不允许 ID 重复，建议叠加时间戳一起用，比如${__time(yyyyMMddHHmmss)}${__Random(1000,9999)}，把碰撞概率降到极低。
6. JMeter 函数常见问题与排查实录
6.1 函数没生效、原样输出？按这个顺序排查
函数原样输出通常是这几个原因：双下划线写成了单下划线、花括号没配对、函数名拼写错误、参数分隔符不对。先用函数助手重新生成一次，复制粘贴替换，能过滤掉 90% 的拼写问题。
如果函数能解析但值不对，比如时间戳一直是同一个，就要考虑“求值时机”。有些取样器参数在线程组初始化的时候被解析并固定，后续不再重新求值。排查方法很简单：加一个 Debug Sampler，打印变量值，看看每次执行的值是否变化。
还有一种情况是函数嵌套太深，像${__V(user_${__counter(FALSE,)})}这种两层嵌套很难一眼看出问题。建议把内层函数的输出先赋值给一个临时变量，再在外层使用。比如先用计数器函数生成index变量，再写${__V(user_${index})}，出问题时排查起来容易得多。
6.2 接口报“未登录、请登录”怎么办：从函数和变量关联角度排查
业务接口报{"code":401,"message":"未登录,请登录!"}，绝大多数不是函数的问题，而是 token 或 session 没有正确传递。排查套路按顺序来：
- 查看登录接口的响应数据里有没有 token 字段，确认返回结构。
- 检查是否用 JSON Extractor 或正则表达式提取器正确提取了 token，提取器里的变量名拼写。
- 用 Debug Sampler 打印变量，确认 token 变量在当前线程里真的有值。
- 检查 HTTP Header Manager 里的参数是不是
${token}，注意变量名大小写是否一致。 - 如果登录和业务接口不在同一个线程组，老老实实用属性传递：登录后置处理器写
props.put("token", vars.get("token"))，业务线程组用${__P(token,)}读取。
这套流程走下来，绝大多数 401 都出在“跨线程组没有用属性传递”这一步。函数本身不背锅，但${__P(token,)}这层皮没包对，问题就会以各种奇怪的形式暴露出来。
6.3 命令行跑压测时的环境坑，顺带解决“命令不存在”问题
Windows 下双击jmeter.bat能启动，但在 PowerShell 里输入jmeter报“无法将‘jmeter’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”，本质就是环境变量没配好。这个问题和你之前遇到的“npm 无法识别为 cmdlet、函数、脚本文件”是同一类问题，解决思路也类似：把 JMeter 的 bin 目录加到 PATH 环境变量里，或者直接使用完整路径调用。
Linux 环境下用的是jmeter.sh，执行前要确认有执行权限。生成报告的命令我前面写过，再强调一次：jmeter -n -t script.jmx -l result.jtl -e -o report_dir。如果脚本里用了${__P(host,默认值)}这类属性占位符，命令行可以用-J参数覆盖：jmeter -Jhost=test.example.com -n -t script.jmx -l result.jtl。
压测过程中想实时看接口响应，又不想用 GUI 占资源，可以在脚本里加“简单数据写入器”（Simple Data Writer），把响应数据落盘到文件。或者更轻量：只对可疑请求打印响应，用“如果控制器 + JSR223 脚本”实现按条件输出。这套组合比开着结果树跑压测靠谱得多。
把函数这块吃透，最大的收益不是背下了多少函数名，而是你在看到参数化、数据关联、动态签名这些需求时，能第一时间判断该用哪个函数、哪种组合，而不是一遇到问题就开始搜索。我个人的组合拳是：造数据优先 CSV + 随机数，跨线程传值优先 JSR223 的props，需要动态时间戳直接__timeShift，断言一律 JSR223 + Groovy。这套用习惯之后，接口测试和性能测试脚本的维护成本会明显降下来。最后分享一个小技巧：把你常用的函数整理成一张速查表贴在工位上，比任何收藏夹都管用。
) 解法详解（AlgoNote 算法通关手册）)
