做接口测试、性能测试的人，迟早会撞上 JMeter 这面墙。我早几年第一次装的时候，差点被环境变量劝退——明明照着教程点了一路下一步，双击 jmeter.bat 就是闪退，后来才知道是 JDK 没配对。这种经历应该不少人有，所以我把从 JDK 安装、JMeter 配置，到跑通第一个接口测试、做一次 100 用户并发压测的完整过程整理出来，新手可以直接照着走，老手也能跳过弯路直接看细节。这篇内容不打算写得像官方文档那样干巴巴，我把当年踩过的坑、现在生产环境里还在用的配置习惯都放进去了，你照着做大概率一次过。
1. Jmeter是什么，为什么测试团队都在用
1.1 从名字说起：JMeter到底解决了什么问题
官方定义里，Apache JMeter 是一个纯 Java 编写的开源工具，最初设计出来是给 Web 应用做负载测试的。但你真把它用起来之后会发现，它的功能边界远不止"压测"这两个字。接口测试、数据库压力测试、FTP 服务验证、JMS 消息队列压测、WebService 调用，甚至命令行程序的执行，它都能干。我见过不少团队直接拿 JMeter 当轻量级接口自动化框架用，配合 Maven 和 Jenkins 跑回归，数据比某些商用工具还靠谱，关键是它免费开源，不用为授权发愁。
那它解决的是什么问题？简单说就是"模拟请求、制造压力、测量表现"。你写了一个下单接口，想知道 100 个人同时点的时候会不会卡；你给公司做了一个报表系统，想知道 500 个用户并发查询时数据库能不能扛住——这些场景就是 JMeter 的主场。它生成一堆虚拟用户（在线程组里配置），让这些用户不断往服务器发请求，然后把响应时间、错误率、吞吐量这些指标收集起来，告诉你系统到底行不行。
1.2 两种身份：接口测试工具与性能测试工具
使用 JMeter 的人通常分成两类，这两类人的用法侧重点完全不一样。
一类做接口测试。他们不关心服务器能扛多大压力，只关心接口返回的数据对不对、状态码是不是 200、参数传进去之后 JSON 响应是否符合预期。这类人常用的组件是 HTTP 请求采样器、断言、JSON 提取器，可能还会配合 CSV 参数化造一批假数据。JMeter 在这类场景里替代的是 Postman 的团队协作功能，优势是脚本可批量执行、可集成到 CI 流程里。
另一类做性能测试。他们关注的是 TPS、响应时间 90 分位值、错误率曲线、资源瓶颈。这类人会在 JMeter 里精心设计线程组，用梯度加压跑 10 分钟、30 分钟甚至几小时，然后用聚合报告和 HTML 报告分析系统瓶颈到底在数据库、应用服务器还是网络层。两类人用到的底层功能差不多，但思路完全不同。我建议你接触 JMeter 的时候，先明确自己现在属于哪一类，再决定先学什么组件，不然容易迷失在一堆英文名词里。
1.3 版本选型：别盲目追新
不少人一上来就问"最新版是多少、装最新版行不行"。我劝你先冷静。JMeter 5.x 系列目前是绝对主流，但不同小版本对 JDK 版本有要求。比如 JMeter 5.4 以后建议 JDK 8 以上，5.5 开始官方默认在 JDK 11 环境测试，5.6 系列则把最低要求提到了 JDK 8 的某个补丁版本以上。如果你电脑里本来就装着 JDK 8，那就别去下载 6.0 之类的超新版本去冒兼容性风险，老老实实用 5.4 或者 5.5 就够。
另一个选型思路是看团队协作环境。如果你们的压测平台、Jenkins 插件、Maven 依赖都锁定在某个 JMeter 版本上，那本地最好也用相同版本，避免脚本在本地和 CI 上跑出不同结果。插件兼容性也是个隐形坑，像jmeter-plugins-manager管理的许多扩展包，有时候只适配到某个主版本，升了 JMeter 之后插件反而装不上了。我的习惯是：本地和一个老版本保持兼容，再去研究新版本特性，而不是上来就格式化硬盘装新版。
2. 安装前的准备工作：JDK安装与环境变量配置
2.1 为什么必须先装 JDK：JVM运行机制
JMeter 是 Java 程序，这一点决定了它的安装顺序——必须先有 Java 运行环境，它才能启动。很多新手在这步翻车，以为把 JMeter 压缩包解压出来双击就能跑，结果jmeter.bat一闪而过，连个报错都看不到。原因就是系统里没有 JVM，Windows 下双击 bat 文件时如果出错，默认会把控制台窗口瞬间关掉，你根本来不及看错误信息。
那为什么不直接装个 JRE 就行？从理论上来讲 JRE 确实够用，但我还是建议装完整的 JDK。原因有两个：第一，JMeter 的部分扩展功能和插件在运行时会动态编译一些 Java/Groovy 代码，缺了 JDK 里的编译器工具，这些功能会报ClassNotFoundException或者编译失败；第二，一台开发机上同时装了多个 Java 工具链是常态，完整的 JDK 在处理JAVA_HOME指向、命令行工具调用时更省心。说白了就是为了少踩一个坑。
2.2 从零配置 JAVA_HOME 环境变量
先下载 JDK。版本建议 JDK 8 或 JDK 11，这两个版本在 JMeter 生态里验证最充分，网上遇到问题也最容易搜到解法。官方下载需要登录 Oracle 账号，嫌麻烦可以去找国内镜像站或各云厂商的 OpenJDK 发行版，只要版本对上就行。安装过程一路下一步，但记住安装目录别带中文、别带空格，推荐直接装在类似C:\Java\jdk-11这样的纯英文路径下。
装完之后需要配置环境变量。Windows 10/11 的操作路径是：右键"此电脑" -> "属性" -> "高级系统设置" -> "环境变量"。在"系统变量"区域新建一个变量，变量名JAVA_HOME，变量值填你的 JDK 安装根路径，比如C:\Java\jdk-11，注意不要带\bin后缀。然后找到Path变量，点编辑，新增一行%JAVA_HOME%\bin。保存退出。
为什么推荐用%JAVA_HOME%\bin这样引用，而不是直接把C:\Java\jdk-11\bin写进 Path？因为以后你升级 JDK 或者切换版本，只需要改JAVA_HOME这一个变量，Path 里的%JAVA_HOME%会自动跟着变。这是个好习惯，不只是 JMeter，后面你用 Maven、Gradle、Tomcat 之类 Java 生态工具，全都依赖这个JAVA_HOME的正确定位。
2.3 验证安装是否成功
配置完环境变量，别急着解压 JMeter，先打开一个新的命令行窗口（这一步必须开新窗口，因为旧窗口不会刷新环境变量），输入：
java -version javac -version如果两行命令都能正常输出版本信息，说明 JDK 装好了。这里有两个坑值得说：
- 输出
javac 不是内部或外部命令但是java -version正常，说明Path配置有问题，大概率是 JAVA_HOME 指向了jre而不是jdk根目录。有些旧版 JDK 安装时默认把 JRE 装到了另一个目录，你指向错了自然找不到编译工具。 - 输出版本和你安装的不一致，说明系统里还有其他 Java 版本抢占了
Path顺序。Windows 在Path里从上往下找命令，如果你想优先用新装的 JDK，把它在Path中的位置往上调即可。这个问题在多人共用电脑、或者装过不同版本开发软件时特别常见。
顺手再跑一下echo %JAVA_HOME%，确认变量值正确。这三步都过了，安装 JMeter 的地基就算打牢了。如果你后面跑 JMeter 还遇到启动问题，回来检查这一步永远不会错。
3. JMeter下载、安装与启动实战
3.1 官方下载渠道与版本选择
下载 JMeter 只有一个官方渠道：Apache 官网的 JMeter 下载页面。打开页面之后你会看到两个主要压缩包，一个是.zip，一个是.tgz。Windows 下用.zip，macOS 和 Linux 下用.tgz。注意它不需要安装程序，压缩包就是安装包，解压到哪里就算装到哪里。
这里多提醒一句：尽量别去第三方软件站下载"JMeter 中文版""JMeter 懒人包"。那些包经常捆绑了旧版本，甚至有人在里面塞了额外插件导致启动报错，出了问题根本说不清。Apache 官网下载速度慢就用镜像站，但也要认准官方镜像列表里的地址。解压之后放到一个整洁的目录，同样别带中文路径，我个人习惯是放在D:\tools\apache-jmeter-5.5这种结构下。
3.2 目录结构详解
解压之后很多人盯着目录发呆，不知道哪些文件管用。我把核心目录讲明白，你就清楚 JMeter 的"身体结构"了：
bin：最核心的启动目录。Windows 双击jmeter.bat，Linux/macOS 运行bin/jmeter。JMeter 的配置文件jmeter.properties、日志文件jmeter.log、证书生成脚本也都在这里。改端口、改语言、调内存，全部围绕这个目录转。lib：JMeter 的依赖库目录。里面放的是工具运行所需的 jar 包，扩展插件也通常装在这里或其下ext子目录。如果你想手动添加数据库驱动 jar，比如 MySQL 的mysql-connector-java，就丢进lib目录后重启 JMeter。extras：辅助脚本目录，主要给 CI 集成和 Ant 调用使用。docs和printable_docs：API 文档和帮助文档，新手可以查，但实际开发中大部分人直接看在线文档。licenses：许可证文件，不用管。
最常用的其实就是bin和lib两个目录。你在实操中遇到的"启动不了、插件不生效、数据库连不上"这类问题，80% 出在这两个目录的配置上。
3.3 启动方式与界面设置
Windows 下进入bin目录，双击jmeter.bat，会弹出一个命令行窗口和一个图形界面窗口。那个命令行窗口千万别手贱关掉，它一关，整个 JMeter 就退出了。很多新手不习惯这种双窗口方式，其实它的作用类似运行日志输出口，JMeter 运行时的系统信息都会打在这里。
启动后的操作界面默认是英文的。对英文不习惯的人，一句话就能改成中文：菜单栏打开Options->Choose Language->Chinese (Simplified)。这是临时生效，下次启动还回到英文。想永久改成中文，就编辑bin/jmeter.properties文件，找到#language=en这一行，去掉注释并改成language=zh_CN，保存后重启 JMeter。
顺便把内存调大这个建议聊透。JMeter 默认堆内存通常是 1G，做简单接口测试完全够，但如果你的压测脚本里线程数上到几百甚至上千，前置变量又多，1G 堆内存很容易报OutOfMemoryError。修改方式是编辑bin下的启动脚本：Windows 编辑jmeter.bat，Linux/macOS 编辑jmeter（无扩展名那个 shell 脚本），找到HEAP="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m"这类行，把-Xmx调大到2g或4g。注意跑压测时 JMeter 本身也占资源，别调太大，否则测试机自己先卡死，压测数据就失真了。我一般控制在 2G 到 4G 之间。
4. 核心使用场景一步步拆解
4.1 第一个接口测试：HTTP请求全流程
JMeter 跑一门接口测试，逻辑上绕不开这几个组件：线程组（Thread Group）、HTTP 请求采样器（HTTP Request Sampler）、监听器（Listener）。你可以把线程组理解成"多少个虚拟用户"，HTTP 请求是"用户具体做了什么动作"，监听器是"把动作结果记录下来"。三者一配，一个最基本的接口测试脚本就成了。
来一个最直接的例子。假设你要测一个 GET 请求，接口路径是http://your.server.com/api/users，返回一串 JSON 用户列表。
第一步，右键"测试计划" -> "添加" -> "线程（用户）" -> "线程组"。 第二步，右键线程组 -> "添加" -> "取样器" -> "HTTP 请求"。 第三步，右键线程组 -> "添加" -> "监听器" -> "察看结果树"。 第四步，在 HTTP 请求面板填协议http、服务器名称或 IPyour.server.com、端口按需填80或8080、方法选GET、路径填/api/users。 第五步，点界面上方的绿色三角形启动按钮，然后点开"察看结果树"，看有没有绿色请求。绿色说明响应成功，红色说明有问题，点开红色请求可以看到具体报错信息和响应内容。
这个流程虽然简单，但有三个细节直接影响能否跑通。路径前必须带斜杠，不带有时候会 404；服务器名称和路径是分开填的，别把整个 URL 塞进服务器名称栏；编码格式如果接口返回中文正常但界面乱码，把"内容编码"填成UTF-8。这些小地方就是经验和高手的差距所在。
4.2 POST请求与参数传递
接口测试最常打交道的是 POST 请求，尤其是那种application/json格式的。操作方法是：在 HTTP 请求采样器里把方法改成POST，然后往Body Data标签页里塞 JSON 字符串，比如：
{ "username": "test01", "password": "abc123" }但只这样填通常会报 415 或者 400，因为服务器不认识你的请求类型。你需要额外添加一个"HTTP 信息头管理器"（右键线程组 -> 添加 -> 配置元件 -> HTTP 信息头管理器），在里面加一行：名称Content-Type，值application/json。加上之后，服务器才知道你发过来的是 JSON，而不是默认的application/x-www-form-urlencoded表单格式。
如果有多个测试用例要跑，一条条塞死数据显然不是正经做法。JMeter 里做参数化最常用的是 CSV 数据文件。线程组下添加"配置元件" -> "CSV 数据文件设置"，填好 CSV 文件路径，变量名一栏起个名字，比如username,password，然后在 HTTP 请求的 Body Data 里用${username}、${password}引用即可。每跑一轮测试，JMeter 会从 CSV 里读下一行数据，这样就实现了不同用例不同参数的批量执行。
如果你需要把上一个接口的返回值传给下一个接口，牵涉到关联，两个核心组件必须会：JSON 提取器和正则表达式提取器。JSON 提取器适合响应体是标准 JSON 的接口，写好$.data.token这种 JsonPath 表达式，拿到值后赋值给变量token，下游接口直接用${token}。正则表达式提取器则用在那些非标准响应上。这个技巧在登录接口拿 token、订单接口传订单号等场景里非常常用。
4.3 HTTPS脚本录制与安全证书处理
手写 HTTP 请求适合接口文档明确的场景，但有时候你面对的是个老系统，API 文档缺失，想看浏览器实际发出的请求，这时候可以用 JMeter 的录制功能。最常见的是 HTTP(S) 测试脚本记录器（HTTP(S) Test Script Recorder），它本质上是一个代理服务器。
操作路径：测试计划右键 -> 添加 -> 非测试元件 -> HTTP(S) 测试脚本记录器。端口默认是8888，配置好之后启动它，然后去浏览器里把代理设置为localhost:8888。一切正常的话，你在浏览器里的操作都会变成 HTTP 请求出现在 JMeter 里。
但录制 HTTPS 请求有一个公认的坑：浏览器会提示证书不受信任，因为 JMeter 代理用的是自己的临时证书。解决办法是安装 JMeter 生成的根证书。在 JMeter 的bin目录下有个名为ApacheJMeterTemporaryRootCA.crt的文件，把它导入到系统"受信任的根证书颁发机构"里，然后重启浏览器和录制器，HTTPS 请求就能正常抓到了。
实操中我的建议是：录制功能主要用于"探测请求长什么样"，而不是代替手写测试脚本。录出来的脚本经常带着一堆静态资源请求（图片、CSS、JS），运行起来干扰真实业务场景。正确姿势是录一遍，看清核心接口的 URL、参数和 Cookie 传递逻辑，然后手动建一个干净的 HTTP 请求脚本，这才是做接口测试和压测该有的脚本。
4.4 上传文件与MD5加密签名
把这两个场景单独拿出来说，是因为它们在实际工作中出现频率极高，但新手很少在教程里学到。
文件上传接口：在 HTTP 请求采样器里，除了 URL 和参数，底部有一个"文件上传"区域。填三个字段：文件名称（本地文件绝对路径）、参数名称（后端接口定义的字段名）、MIME 类型（比如image/png）。这样 JMeter 发请求时会自动以multipart/form-data格式携带文件。一个小细节：如果你同时传普通参数和文件，要把那些普通参数放在"参数"标签页，文件放在"文件上传"标签页，两边互不干扰。
MD5 加密签名：很多接口出于安全考虑，会在请求参数里带一个签名串，常见做法是把时间戳、token、请求体拼接后用 MD5 取摘要。JMeter 里生成 MD5 可以用内置的__digest函数，格式是${__digest(MD5,要加密的内容,,,)}。如果加密逻辑复杂，拼接规则多样，我更推荐用JSR223 预处理器写 Groovy 脚本，比如：
import java.security.MessageDigest def body = "test01abc123" def md5 = MessageDigest.getInstance("MD5").digest(body.bytes) def sign = md5.collect { String.format("%02x", it) }.join() vars.put("sign", sign)Groovy 可以直接调 Java 类库，还能往变量里传值，用起来远比 BeanShell 方便。记住一点：JMeter 高版本（3.1 以后）官方建议用 JSR223 + Groovy，不是因为它更高级，而是因为 Groovy 脚本性能远好于 BeanShell，压测时脚本引擎不会成为瓶颈。
5. 性能压测实操：模拟100个并发用户
5.1 线程组的设计思路
到了压测这一步，你就要把视角从"接口对不对"切换到"系统扛不扛得住"。线程组就是模拟并发的基本容器。双击线程组，面板上有几个关键参数：线程数、Ramp-Up 时间、循环次数。
假设需求是"模拟 100 个用户同时访问一个登录接口"，在线程数里填100。但要知道，这 100 个虚拟用户并不是在同一毫秒内"砰"地全部冲上去。Ramp-Up 时间告诉 JMeter 用多长时间把这些线程全部启动起来。如果填10，意味着 10 秒内启动 100 个线程，也就是每秒启动 10 个。这个参数很有用，它能模拟用户逐渐到达的效果，避免测试刚开始的一瞬间把服务器打崩，导致数据失真。如果需求是真正的瞬时并发，可以把 Ramp-Up 设为 0 或 1 秒。
循环次数是"每个用户跑几遍"。填1表示每个用户只发一次请求；如果想让请求持续不断，就勾选"调度器"，设置持续时间，比如600秒，表示 600 秒内持续加压。我建议新手做压测时一定要分清这两个概念的差别：循环次数和持续时间控制的是"压力时间长短"，线程数和 Ramp-Up 控制的是"压力强度"。做一次有说服力的压测，这两个维度都得根据业务场景设计好。
5.2 添加监听器与执行压测
压测过程中怎么"看"数据？靠监听器。最常用的有这几个：察看结果树（看单个请求成功失败和响应详情）、聚合报告（看平均响应时间、TPS、错误率等汇总指标）、图形结果（看趋势曲线）。压测开始前，在线程组下添加一个"聚合报告"监听器即可。注意"察看结果树"在压测时尽量少用或者只在调试时用，因为它会把每个请求的响应体都存到内存里，100 并发以上的时候内存暴涨，可能导致 JMeter 自己先挂掉。压测时更稳妥的做法是：先小并发调试，确认请求无误，再上大并发，把察看结果树关掉或移除。
正式压测还有两种执行方式。图形界面里点绿色启动按钮，适合调试和小规模测试；生产级别的大压测建议用命令行模式，命令是这样的：
jmeter -n -t test.jmx -l result.jtl -e -o report_dir参数解释一下：-n表示非 GUI 模式，-t指定测试脚本文件，-l输出原始结果文件（.jtl），-e -o在指定目录生成 HTML 格式的 Dashboard 报告。命令行跑压测的好处是省内存、结果稳定、不会被界面操作干扰。压测完成后，report_dir里就是一个完整的 HTML 测试报告，直接用浏览器打开即可。
5.3 压测报告的关键指标怎么看
生成报告之后，别只看一眼"有没有挂"就完事，压测的意义全在指标解读上。我常用而且建议你看的几个：
- Samples：总共发了多少次请求。
- Average：平均响应时间，单位毫秒，反映整体快不快。
- 90% Line / 95% Line / 99% Line：90/95/99 分位响应时间，意思是 90% 的请求在这个时间以内返回。这个指标比平均值更能反映极端卡顿情况，平均值很好看但 99% 线飙高，说明存在明显短板请求。
- Error %：错误率，一般接口测试要求 0，性能测试要看业务容忍度。
- Throughput：吞吐量，单位是
requests/sec，这就是大家常说的 TPS。 - Received KB/sec：每秒接收的数据量，可以用来判断是否网络带宽先打满了。
如果压测结果出来，发现 TPS 很低、响应时间一路上涨，大概率不是 JMeter 的问题，而是被测系统出现了瓶颈。常见方向是：数据库连接池打满了、应用线程池满了、Redis 缓存命中率太低、或者代码里出现了明显的慢查询。这时候该去检查服务端监控，JMeter 本身不能告诉你瓶颈在哪，它只能告诉你"现在确实有问题"。很多新手做压测最大的误区，就是以为压测工具能给出优化建议，它给出的永远是数据，分析的人必须是你自己。
6. 常见问题与排查技巧实录
6.1 启动闪退怎么办
这是所有 JMeter 新手的噩梦，双击jmeter.bat屏幕一闪就没了，什么信息都看不到。常规原因是没装对 JDK 或环境变量没配对。排查方式：打开命令行（cmd），切到 JMeter 的bin目录，手动输入jmeter.bat执行，这样报错信息会留在命令行窗口里，不会一闪而过。看到类似JAVA_HOME is not set的提示，就回去检查 JDK 安装和环境变量。
另一个常见的闪退原因是 JDK 版本太新。比如有些人装了 JDK 17 以上，再跑老版本 JMeter，可能因为模块系统限制或移除了某些类导致启动失败，报错信息里常见ClassNotFoundException。这时候要么把 JDK 换成 8 或 11，要么换新版本 JMeter。我的建议是给机器上装一个 JDK 8 打底，大部分 Java 老工具靠它都能活。
6.2 察看结果树请求为空或全是红色
压测跑完了，打开察看结果树，发现请求全是红色，或者干脆没有任何记录。红色通常意味着服务端返回了非 2xx 状态码，或者客户端根本连不上。点开后重点看"响应报文"标签页里的信息：如果是Connection refused，检查服务器 IP 和端口是否可达；如果是404 Not Found，检查路径是不是填错了；如果是500 Internal Server Error，那是服务端程序问题，JMeter 无能为力，去找开发看日志。
结果树完全没数据的情况，多半是监听器加错了位置，或者测试计划没有被正常"包含"当前线程组。检查一下线程组是否在测试计划根节点下面，监听器是否挂在线程组节点下。还有一个小概率情况是取样器被误删或者脚本文件损坏，重新建一次请求即可。排查这类问题时我习惯"拆小化"：新建一个最简单的 HTTP 请求脚本，只请求官网首页，如果这个能通，说明环境没问题，问题出在你原有的脚本配置上。
6.3 resultcollector.action_if_file_exists 弹窗问题
这个报错对应的场景是：你在 GUI 模式执行脚本，结果文件已经存在，JMeter 弹出一个窗口问你是"覆盖"还是"追加"。如果这个弹窗出现在命令行模式或者 CI 环境里，就会导致进程一直卡住不继续跑。
要彻底解决，编辑bin/jmeter.properties，搜索resultcollector.action_if_file_exists这个配置项。默认值一般是ASK（每次都问），你可以改成APPEND（追加写）或NONE（直接忽略，视具体版本而定，有些版本是DELETE）。我日常跑自动化时设置为APPEND并配合-f参数在启动命令里强制清理旧文件，这样既不会因为弹窗挂起，也不会让旧数据混进新结果里。配置修改后要重启 JMeter 才生效。
顺便说一句，类似这种"卡在某一步不动"的问题，排查看日志依然是第一手段。JMeter 的日志文件在bin目录下，文件名jmeter.log，里面会记录启动信息、报错堆栈和插件加载情况。GUI 界面菜单栏也有"选项" -> "日志查看器"，实时看日志很方便。遇到诡异问题先开日志，比自己盲目改配置高效得多。
6.4 响应报文中文乱码与编码问题
中文乱码是接口测试里出镜率极高的问题，原因在于 JMeter 默认解析响应体时用的是 ISO-8859-1 编码，而大部分业务接口返回的是 UTF-8。两种保留方案，二选一：
方案一，最推荐：编辑bin/jmeter.properties，找到#sampleresult.default.encoding=ISO-8859-1，把注释去掉并改成sampleresult.default.encoding=UTF-8，保存重启。改完之后所有新请求默认按 UTF-8 解码，一劳永逸。
方案二，临时应对：在 HTTP 请求采样器的"内容编码"栏手动填UTF-8。这种方式只对单个请求生效，适合你不想改全局配置的场景。注意如果接口响应本来是 GBK，那填 UTF-8 反而会乱上加乱，需要根据实际情况换成GBK。
6.5 证书错误与 HTTPS 抓不到包
录制 HTTPS 脚本时最常见两个问题：浏览器提示证书不可信，或者录了半天一个请求都没有。第一个问题按前文说的导入ApacheJMeterTemporaryRootCA.crt证书就行。第二个问题，先检查代理设置是否真的生效：打开浏览器的代理设置，确认 HTTP 和 HTTPS 代理都指向localhost:8888。还要注意 JMeter 录制器中的"目标"配置，如果设置了"排除模式"，有些请求可能被规则过滤掉了，排查时可以把排除规则先清空再试。
另外一个容易被忽略的点：JMeter 的录制器和被测站点如果跑在同一台机器上，且站点也监听了 8888 端口（不太常见但确实有人遇到），端口冲突会导致录制失败。监听的端口换一个，比如改成8889，再试试，问题基本就解了。
6.6 同生态工具链的搭配经验
最后聊几句 JMeter 在实际工作里很少单独存在。我看到很多人在搜 JMeter 安装时，旁边总跟着 Git、Maven、Node.js、Vue 这些词。这其实是典型的前后端联调环境。JMeter 做接口测试和压测，Maven 做 Java 项目构建、管理 JMeter 脚本的依赖和插件，Git 用来管理.jmx脚本文件的版本，Node.js 和 Vue 环境通常是给前端项目配合联调用的。它们之间不会互相依赖，但经常出现在同一台开发机上。
我自己的习惯是：JMeter 脚本放进 Git 仓库，用 Maven 项目里配置jmeter-maven-plugin在 CI 上自动跑接口回归；本地测前端联调时，JMeter 模拟后端接口返回数据，让前端先跑起来。这套组合拳玩熟了，整个测试效率会高很多。但如果你现在还在为启动闪退挠头，先别想这么远，把前五章的内容扎实过一遍再说。
回头再强调一遍那个最容易被忽略但最关键的环节：JMeter 的一切功能都建立在 JDK 环境正确的基础上。很多人今天装好了用着没事，明天换了个电脑或者升了个级又开始闪退，四处查插件、查配置，最后发现还是JAVA_HOME指错了。所以我个人的习惯是把 JDK 安装路径、版本号记在一个地方，新环境配好之后第一件事永远是跑java -version和echo %JAVA_HOME%验证。环境对了，后面的路就顺了。
