Jmeter接口测试与性能测试实战：从环境搭建到结果分析

很多朋友刚开始接触接口测试和性能测试时，习惯先去搜索各种工具，然后发现 Jmeter 的资料虽然多，但大多比较零散：有的只讲安装，有的只讲某个元件，很少有能把接口测试和性能测试串起来、带着真实项目走一遍的完整教程。本文就围绕 Jmeter 接口测试与 Jmeter 性能测试这两条主线，从零开始搭建环境，再通过一个模拟电商项目中的真实接口场景，一步步完成接口请求、参数化、关联、断言，以及性能测试中的线程组设置、监听器分析和结果解读。无论你是刚入门测试的新人，还是准备在项目中落地压测的开发者，都可以对照本文操作。

1. 接口测试与性能测试，为什么要选 Jmeter

在动手操作之前，先把概念理清楚。很多初学者容易把“接口测试”和“性能测试”混为一谈，或者觉得它们是两套完全独立的东西。实际上，两者关系非常紧密：接口测试保证了单个接口的功能正确性，性能测试则验证了接口在并发压力下的稳定性。而在 Jmeter 里，这两类工作可以共用同一套脚本体系，这也是 Jmeter 在测试领域长期占据重要位置的原因。

1.1 接口测试到底是测什么

服务端接口测试，本质上是在不经过页面 UI 的情况下，直接对后端提供的 HTTP 接口发起请求，然后验证返回的数据是否符合预期。比如一个登录接口，我们需要验证：

• 传入正确的用户名密码，是否返回 token 和用户信息。
• 传入错误的密码，是否返回明确的错误码。
• 缺少必填参数时，接口是否给出参数校验提示。
• 请求方法用错时（比如 GET 写成 POST），是否返回 405。

这些验证内容，用 Jmeter 都可以完成。Jmeter 通过线程组模拟请求发起方，用 HTTP 请求采样器组装请求数据，再用断言来判断返回结果是否正确。整个流程不需要写复杂的代码，通过图形界面拖拽配置即可完成。

1.2 性能测试解决什么问题

性能测试的核心是回答三个问题：系统能承受多少并发用户？在并发过程中响应时间是否满足要求？系统在持续压力下会不会崩溃或出现资源耗尽？

Jmeter 通过线程组中的线程数、循环次数、Ramp-Up 时间来模拟不同规模的并发请求。注意，这里的“线程数”并不完全等同于“真实用户数”，因为 Jmeter 线程会以最快速度不间断地发送请求。更准确的理解是：线程数代表“同时活跃的请求数量”，而真实用户场景通常还需要通过常数吞吐量定时器或将思考时间考虑进来。

1.3 为什么 Jmeter 是入门首选

相比 LoadRunner、Apifox、Postman 等工具，Jmeter 的优势非常明显：

• Apache 开源免费，安装包小，跨平台支持 Windows、macOS、Linux。
• 基于 Java 开发，只要本机有 JDK 即可运行。
• 插件生态丰富，支持各种协议和监控集成。
• 既适合单接口调试，也适合复杂场景压测。
• 脚本本质是 XML 文件，方便团队共享和后续集成到 CI/CD 流水线。

当然，这并不是说其他工具不好。比如 Postman 在接口调试的便捷性上非常好，Apifox 在接口文档管理和 Mock 方面有优势，LoadRunner 在企业级大型压测中依然有市场。但在“接口测试 + 性能测试一体化学习”这件事上，Jmeter 仍然是最适合系统学习的工具。

2. 环境准备：JDK 与 Jmeter 安装配置

Jmeter 本身不需要安装，解压即用，但它依赖 Java 运行环境。所以在安装 Jmeter 之前，先确保本机 JDK 正确安装并配置好了环境变量。

2.1 JDK 安装与环境变量配置

建议使用 JDK 8 或 JDK 11。较新的 Jmeter 5.x 版本对 JDK 版本有一定要求，通常 JDK 8 以上即可，但为了避免兼容问题，推荐 JDK 11。以 Windows 为例，安装 JDK 后需要配置 JAVA_HOME。

验证是否安装成功，打开命令行并输入：

java -version

如果显示类似下面信息，说明 JDK 配置成功：

java version "1.8.0_301" Java(TM) SE Runtime Environment (build 1.8.0_301-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.301-b09, mixed mode)

如果提示“java 不是内部或外部命令”，说明环境变量没有配置好，需要检查 JAVA_HOME 和 Path。

2.2 Jmeter 下载与启动

Jmeter 官方下载地址是 Apache Jmeter 官网，推荐下载二进制版本，例如 apache-jmeter-5.6.3.zip。下载完成后解压到本地目录，注意路径中尽量不要包含中文和空格，否则某些版本的 Jmeter 在后续保存脚本时可能出现乱码问题。

解压后的目录结构大致如下：

apache-jmeter-5.6.3/ ├── bin/ ├── docs/ ├── extras/ ├── lib/ └── LICENSE

进入 bin 目录，Windows 用户双击 jmeter.bat 启动图形界面；macOS 或 Linux 用户执行 jmeter.sh。

cd apache-jmeter-5.6.3/bin sh jmeter.sh

启动后出现 Jmeter 主界面，默认会有一个测试计划节点。为了后续操作稳定，建议在启动前先确认一下 Jmeter 界面语言。如果显示英文，可以通过菜单栏 Options -> Choose Language 切换为中文，方便新手学习。中文选项中有“简体中文”，选择后立即生效，无需重启。

2.3 快速验证安装是否正常

启动成功后，先做一个最简单的验证：在测试计划下新增线程组和 HTTP 请求，访问一个公开接口，比如 httpbin.org 的 GET 接口，然后运行看结果。

在这里只强调一个点：Jmeter 默认启动的是 GUI 模式，这种模式适合脚本调试，但不适合实际压测。真正压测时，建议使用命令行模式：

jmeter -n -t test.jmx -l result.jtl -e -o report

后面的实战环节会专门讲解命令行压测和报告生成。

3. Jmeter 核心元件剖析

Jmeter 的脚本并不是简单地把请求发给服务器，而是由各种“元件”组合成完整的测试逻辑。理解这些元件的分类和作用，是学会 Jmeter 的关键。很多新手一开始就陷入“一个一个按钮乱点”的状态，根本原因就是没有建立 Jmeter 的元件体系认知。

3.1 元件分类

Jmeter 的元件按照功能可以分为以下几类：

• 配置元件：用来提供变量、CSV 数据、默认请求属性等。比如 CSV 数据文件设置、HTTP 请求默认值。
• 前置处理器：在请求发送之前执行，常用于参数预处理、签名生成。
• 取样器：真正发送请求的元件。HTTP 请求、JDBC 请求、Debug 采样器都属于取样器。
• 后置处理器：在请求返回之后执行，常用于从响应中提取数据。正则表达式提取器、JSON 提取器都属于这一类别。
• 断言：验证响应是否符合预期，比如响应断言、JSON 断言、持续时间断言。
• 监听器：收集和展示测试结果，比如查看结果树、聚合报告、图形结果。
• 定时器：控制请求发送的频率，模拟用户思考时间。
• 逻辑控制器：控制请求执行逻辑，如循环控制器、如果控制器、事务控制器。

这里有一个常见误区：测试计划和线程组不属于以上任何单一分类，它们是整个脚本的“容器”结构。测试计划是根节点，线程组是具体执行场景的入口。

3.2 测试计划与线程组

测试计划是 Jmeter 脚本的最顶层结构。测试计划中可以添加“用户自定义变量”，这些变量对整个脚本全局有效。比如服务器地址、端口号、公共请求头等都可以放在这里。

线程组是具体执行场景的容器。线程组中有几个重要参数：

线程数和循环次数的组合，决定了总的请求量。比如线程数 10、循环次数 100，总请求数就是 1000。

3.3 取样器与监听器

取样器中最常用的是 HTTP 请求。HTTP 请求中需要配置协议、服务器名称或 IP、端口号、方法、路径、请求体等。

监听器用来观察测试结果。常用的几个监听器包括：

• 查看结果树：调试脚本时最常用，可以查看每个请求的请求数据和响应数据。
• 聚合报告：统计总请求数、平均响应时间、中位数、90% 响应时间、错误率、吞吐量。
• 图形结果：展示响应时间随请求变化的趋势。

性能测试时，查看结果树这种监听器会严重影响 Jmeter 自身性能，所以在压测阶段不应该使用它。压测过程中直接使用命令行模式，结束后再打开聚合报告或生成 HTML 报告。

4. 接口测试项目实战：模拟电商系统登录到下单全流程

下面进入真正的项目实战。为了贴近真实环境，这里以“模拟电商平台”为例，完成从登录、查询商品、添加购物车到提交订单的完整接口链路测试。整个流程会覆盖 Jmeter 的常用功能：参数化、关联、断言、事务控制器。

4.1 项目接口说明

假设被测系统提供了以下接口（本文以模拟接口地址演示，实际测试时替换为真实环境）：

这些接口之间存在依赖关系：登录后才能调用商品列表，添加购物车需要商品 ID，提交订单需要购物车 ID。这正是接口测试中典型的“关联”场景。

4.2 创建测试计划与线程组

打开 Jmeter，在测试计划上右键，选择“添加 -> 线程（用户） -> 线程组”。

线程组名称修改为“电商接口测试线程组”。线程数设置为 1，循环次数设置为 1，因为这是功能性的接口测试，先保证流程正确，不涉及并发。

接下来在线程组下添加 HTTP 请求默认值。作用是将服务器地址、端口号等公共信息提取出来，这样每个 HTTP 取样器就不需要重复填写服务器地址。

右键线程组 -> 添加 -> 配置元件 -> HTTP 请求默认值，填写：

• 协议：http
• 服务器名称或 IP：demo-api.example.com
• 端口号：8080

然后添加 HTTP 信息头管理器：

• 添加 -> 配置元件 -> HTTP 信息头管理器

请求头中添加 Content-Type: application/json，后续所有请求都会带上这个头。

4.3 第一个接口：用户登录

在线程组下添加 HTTP 请求，名称修改为“用户登录”。

配置内容：

• 方法：POST
• 路径：/api/user/login
• 请求体：

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

在 Body Data 标签页中填入上述 JSON。运行后，在查看结果树中可以看到响应。

为了验证接口是否正确，在线程组下添加“查看结果树”监听器，运行脚本，查看响应内容。正常响应类似：

{ "code": 200, "message": "success", "data": { "token": "eyJhbGciOiJIUzI1NiJ9.xxx", "userId": 1001, "nickname": "测试用户" } }

这里返回的 token 是后续接口的“通行证”，需要提取出来。这就是接口测试中非常重要的“关联”操作。

4.4 使用 JSON 提取器完成 token 关联

Jmeter 中提取 JSON 响应内容，推荐使用 JSON 提取器。右键“用户登录”请求 -> 添加 -> 后置处理器 -> JSON 提取器。

配置如下：

• 变量名称：loginToken
• JSON 路径表达式：$.data.token
• 匹配编号：1
• 默认值：TOKEN_NOT_FOUND

设置完成后，后续请求可以通过 ${loginToken} 引用这个 token 值。

如果接口返回的不是标准 JSON，或者 JSON 路径表达式不够用，可以使用正则表达式提取器。比如：

• 正则表达式："token":"([^"]+)"
• 模板：$1$
• 匹配编号：1

这里需要理解一个概念：JSON 提取器适用于响应体是 JSON 格式的接口；正则提取器适用范围更广，但编写规则需要更仔细。接口响应是标准 JSON 时，优先使用 JSON 提取器，更直观、更稳定。

在登录接口后面再添加一个 HTTP 信息头管理器，通过“添加配置元件”的方式，将 token 放到请求头中：

Authorization: Bearer ${loginToken}

注意：这个信息头管理器要放在登录接口之后的层级下，这样后面的商品列表、添加购物车、提交订单接口就会自动携带这个请求头。

4.5 第二个接口：商品列表与商品 ID 提取

添加 HTTP 请求，名称为“商品列表”。

• 方法：GET
• 路径：/api/product/list

运行后，响应中会返回商品列表：

{ "code": 200, "data": [ { "productId": 501, "productName": "手机", "price": 1999 }, { "productId": 502, "productName": "耳机", "price": 299 } ] }

后续添加购物车需要用到 productId，这里继续用 JSON 提取器提取第一个商品的 ID：

• 变量名称：productId
• JSON 路径表达式：$.data[0].productId
• 匹配编号：1
• 默认值：PRODUCT_NOT_FOUND

如果是提取全部商品 ID 用于循环测试，可以把匹配编号设为 -1，表示匹配所有结果，但那样变量的引用方式是 ${productId_1}、${productId_2}，使用时会稍复杂。初学者先掌握提取第一个元素就足够。

4.6 第三个接口：添加购物车与购物车 ID 提取

添加 HTTP 请求，名称为“添加购物车”。

• 方法：POST
• 路径：/api/cart/add
• 请求体：

{ "productId": ${productId}, "quantity": 1 }

这里的 ${productId} 引用前面提取到的商品 ID。运行后，如果接口正常，会返回 cartId 或 cartItemId。

同样使用 JSON 提取器提取：

• 变量名称：cartId
• JSON 路径表达式：$.data.cartId
• 匹配编号：1
• 默认值：CART_NOT_FOUND

4.7 第四个接口：提交订单

添加 HTTP 请求，名称为“提交订单”。

• 方法：POST
• 路径：/api/order/submit
• 请求体：

{ "cartId": ${cartId}, "addressId": 8001 }

到此，一个完整的“登录 -> 查询商品 -> 加购 -> 下单”的接口链路就完成了。运行整个测试计划，如果一切正确，四个请求都会显示绿色成功状态。

4.8 添加响应断言

只有请求成功还不够，还需要验证接口返回的数据是否正确。Jmeter 中常用响应断言来校验响应内容是否包含某个关键字。

右键“用户登录”请求 -> 添加 -> 断言 -> 响应断言。配置：

• 响应字段：响应文本
• 匹配规则：包含
• 测试模式：success

这样，如果登录接口返回的文本中没有包含“success”字符串，断言就会失败，请求会被标记为红色。

更严谨的接口测试，建议针对每个接口分别添加合理的断言。比如商品列表接口断言包含“productName”，添加购物车接口断言包含“cartId”。断言不是越多越好，但也不能完全不写。完全没有断言的脚本，即使接口返回 500，只要响应时间正常，在 Jmeter 中也不会被判定为失败，这会严重影响后续性能测试结果的可信度。

4.9 接口测试中的参数化

真实的测试场景中，不可能所有用户都使用同一个账号。Jmeter 的参数化，就是让不同请求使用不同的测试数据。

Jmeter 常用参数化方案有：

• 用户自定义变量：使用固定值，适合稳定的环境参数。
• CSV 数据文件设置：从外部文件读取数据，适合大量用户数据。
• 函数助手：比如 __Random、__time 等动态函数。

CSV 数据文件设置是最常用的。首先准备一个 data.csv 文件：

username,password user001,123456 user002,123456 user003,123456

在线程组下添加“配置元件 -> CSV 数据文件设置”，配置：

• 文件名：/path/to/data.csv
• 文件编码：UTF-8
• 变量名称：username,password
• 分隔符：,

然后修改登录请求的 Body Data：

{ "username": "${username}", "password": "${password}" }

这样，每个线程执行时都会从 CSV 中取出一行数据。这里需要注意一个细节：如果并发执行时 CSV 数据文件中的数据量少于线程数，可能出现数据不足的问题。生产级压测时，要确保测试数据足够，或者开启 CSV 数据文件设置中的“循环”选项。

4.10 接口同时跑多个线程的实践

很多朋友会遇到“模拟登录后同时跑 5 个线程跑查询接口”的需求。比如先用一个账号登录，然后让 5 个并发用户同时查询商品列表。

实现方式有两种：

方式一：在同一个线程组中，通过“常数吞吐量定时器”或“同步定时器”控制并发节奏。但这种方式比较粗糙，不容易精确模拟“只对查询接口并发”的场景。

方式二：使用“setUp 线程组 + 普通线程组”。setUp 线程组先执行登录，登录得到的 token 以属性（props）方式保存；普通线程组中的 5 个线程在请求时读取该属性。

setUp 线程组中登录脚本添加 JSR223 后置处理器，使用 Groovy 脚本把 token 存到全局属性中：

props.put("globalToken", vars.get("loginToken"));

普通线程组的查询接口请求头中，可以直接引用${__P(globalToken,)}。这样就能实现“先登录一次，再并发查询”的常见场景。

5. Jmeter 性能测试完整实战

接口测试通过后，接下来进入性能测试环节。性能测试不是简单地把线程数调大，而是有一套标准的步骤和指标解读方法。

5.1 性能测试的完整步骤

标准性能测试流程可以拆成以下步骤：

1. 确定性能测试目标。比如：系统需支持 500 并发用户，平均响应时间小于 2 秒，错误率低于 1%。
2. 准备测试环境。尽量使用与生产环境隔离的测试环境，避免压测影响线上业务。
3. 编写或复用接口测试脚本。
4. 设置性能测试场景。比如阶梯加压、持续压测、峰值压测。
5. 执行压测。通过命令行方式运行，避免 GUI 性能干扰。
6. 监控系统资源。查看 CPU、内存、网络、数据库连接池等指标。
7. 分析测试结果。输出聚合报告、HTML 报告，定位瓶颈。
8. 回归验证。优化后重新压测，对比结果是否改善。

5.2 性能测试线程组设置

以“模拟登录后同时跑 5 个线程跑查询接口”为例，把普通线程组配置为：

• 线程数：5
• Ramp-Up 时间：1
• 循环次数：100

Ramp-Up 时间的作用是让线程在指定时间内逐步启动，而不是瞬间同时发起。如果 Ramp-Up 设置为 1，代表 5 个线程在 1 秒内全部启动，基本上属于瞬时并发。

如果要做更真实的容量测试，建议线程数设置为 50，Ramp-Up 时间设置为 10，循环次数设置为 200。此时总请求量为 10000。

还可以结合“聚合报告”观察响应时间分布。聚合报告中的关键指标解读：

5.3 性能测试命令行的使用

GUI 模式跑压测有个致命问题：Jmeter 自身的界面渲染、监听器数据收集都会消耗系统资源，导致压测结果不准确。特别是在大并发场景下，GUI 模式本身就是瓶颈。正确做法是使用命令行模式。

将脚本保存为 test_plan.jmx，放到 bin 目录下或指定路径，执行：

jmeter -n -t test_plan.jmx -l result.jtl -e -o report

参数说明：

• -n：非 GUI 模式。
• -t：指定测试脚本路径。
• -l：指定结果文件路径，保存为 JTL 格式。
• -e：测试结束后生成 HTML 报告。
• -o：HTML 报告输出目录。

注意：结果文件和报告目录不能已存在，否则会报错。如果希望保留多次压测结果，建议每次压测都创建新的目录，例如 report_20260316_001 这样的命名方式。

执行过程中，控制台会输出实时进度：

summary + 2000 in 00:00:10 = 200.0/s Avg: 450 Min: 210 Max: 1200 Err: 0 (0.00%) summary + 3000 in 00:00:15 = 200.0/s Avg: 480 Min: 200 Max: 1500 Err: 10 (0.33%)

这一行数据包含了实时吞吐量、平均响应时间、错误率等信息。

压测结束后，打开 report 目录下的 index.html，可以看到 Jmeter 生成的 HTML 报告，包含图形化的性能指标、响应时间分布、错误统计、吞吐量趋势等信息。这个报告用于团队评审和性能分析非常方便。

5.4 参数化在性能测试中的应用

性能测试中，参数化同样重要。但需要特别注意：如果性能测试脚本中使用了 CSV 参数化，要确保 CSV 文件中的数据量远大于总请求数，否则会出现“数据用尽”的情况。CSV 数据文件设置中有两个选项“遇到文件结束符再次循环”和“停止线程”，需要按照测试目标选择。

如果希望模拟不同用户名的并发登录，可以在 CSV 数据文件设置中勾选“遇到文件结束符再次循环”，这样数据会重复使用。但如果 token 登录会被服务端去重，重复使用同一账号可能造成数据冲突，这时需要准备足够多的测试账号。

6. 常见问题与排查思路

Jmeter 使用过程中，新手会遇到各种各样的问题。这里整理几个高频问题，并给出排查思路。

关于 Jmeter 安全证书的问题也需要补充：当录制或测试 HTTPS 接口时，Jmeter 会提示证书不受信任，或者请求返回握手失败。解决方案分为两种：如果是测试环境，可以在 Jmeter 的 bin 目录下找到 ApacheJMeterTemporaryRootCA.crt 证书并导入到本机受信任的根证书颁发机构；如果是生产环境的业务接口，一般由企业统一签发证书，不需要 Jmeter 再去生成临时证书。

7. 最佳实践与工程建议

Jmeter 的脚本是测试团队的资产，脚本质量直接影响测试的准确性和可维护性。以下是一些来自实际项目的建议。

7.1 脚本命名与结构规范

• 每个线程组、取样器、监听器都必须有清晰可读的名称。
• 建议在取样器名称中包含被测接口的含义，比如“登录-获取token”“商品列表-查询”。
• 添加断言时，断言名称要说明验证点，比如“断言-登录返回success”。
• 测试计划中不要出现无意义的默认名称，比如“HTTP 请求”。

7.2 配置与脚本分离

• 将服务器地址、端口号、测试环境标识等配置放到“用户自定义变量”或“HTTP 请求默认值”中。
• 不同环境的配置建议使用独立的 properties 文件或通过命令行参数传入，而不是每个脚本都写死一遍。
• 使用 -J 参数可以在命令行中动态指定属性值，例如：

jmeter -n -t test_plan.jmx -Jserver.host=test.example.com -Jserver.port=8080 -l result.jtl -e -o report

这样一来，同一份脚本可以在测试环境、预发环境、生产环境之间灵活切换，无需修改脚本文件。

7.3 性能测试中的数据与监控

• 压测前确认测试数据量充足，尤其是登录账号、商品 ID 等业务主键数据。
• 压测时不仅看 Jmeter 的响应指标，还要关注被测服务器的 CPU、内存、磁盘 IO、网络带宽、数据库连接池等指标。
• 推荐使用 Jmeter InfluxDB 插件 + Grafana 实现实时性能监控。Jmeter 将测试数据写入 InfluxDB，Grafana 从 InfluxDB 读取数据生成可视化仪表盘，可以实时查看吞吐量、响应时间、错误率等关键指标的变化趋势。
• 性能测试报告要保留现场信息：压测时间、版本号、线程数、测试数据量、服务器配置等，否则发现问题后难以回溯。

7.4 HTTP 请求中的异常处理

接口测试过程中，建议开启“从 HTML 文件获取所有内含的资源”时谨慎使用。性能测试中，除了被测接口外，不要勾选这个选项，否则 Jmeter 会额外请求页面中的图片、CSS、JS 等静态资源，干扰压测结果。

另外，HTTP 请求中“跟随重定向”和“自动重定向”的区别需要理解：自动重定向只适用于 GET/HEAD 请求，而且不会记录重定向过程；跟随重定向会记录每一步重定向请求，适用于 POST 后返回 302 再跳转的场景。在接口测试中，建议使用“跟随重定向”，便于定位问题。

7.5 日志与结果保存

• 使用命令行压测时，-l 参数生成的 JTL 文件是原始结果数据，建议每次都保留。
• HTML 报告目录以时间戳命名，例如 report-20260316-1400，避免覆盖历史报告。
• 调试脚本时使用查看结果树，正式压测时务必移除或禁用该监听器。

8. 学习路线与后续扩展

到此，你已经完成了从 Jmeter 安装、接口测试脚本编写、参数化与关联、性能测试场景设置到结果分析的一整套流程。这套知识体系足够支撑你在日常工作中独立完成中小型项目的接口测试和性能摸底。

接下来如果想继续深入，可以从下面几个方向选择：

1. 深入学习 Jmeter 函数与 BeanShell/JSR223 脚本，完成更复杂的签名生成、加密参数、响应解密等场景。
2. 学习 Jmeter 分布式压测，解决单机无法模拟大并发的问题。
3. 学习 Jmeter 与 Maven/Jenkins 集成，把接口测试和性能测试接入 CI/CD 流水线。
4. 学习 InfluxDB + Grafana + Jmeter 的实时监控体系，打造团队级性能测试平台。
5. 了解其他测试工具，比如 Postman、Apifox、LoadRunner 的适用场景，做横向对比但不要盲目切换。

最后，建议你动手把本文的模拟电商接口流程完整地操作一遍。可以从简单的登录接口开始，先把环境跑通，再逐步增加商品查询、加购、下单的关联逻辑，最后加大线程数观察响应时间的变化。性能测试没有捷径，多跑几次不同的场景配置，看实际数据来理解线程数、Ramp-Up 时间、循环次数和最终吞吐量之间的关系，会比背任何理论都有效。

如果本文对你有帮助，可以收藏备用。后续遇到 Jmeter 的报错或性能测试指标问题，也欢迎在评论区交流。