这次我们直接来聊 JMeter。不管是做接口测试还是性能测试JMeter 几乎是国内测试岗绕不开的一个工具。它的定位很明确一个开源的、基于 Java 的负载测试工具既能用来跑单接口的功能验证也能用来做整套服务的压力测试。很多人刚接触测试的时候往往先学 Postman 再学 JMeter但真正进入企业级项目之后会发现JMeter 的价值在于它把接口测试、数据驱动、批量任务、分布式压测和报告产出整合在了一条链路上这套能力是普通接口调试工具替代不了的。这篇文章的信息密度会比较高。我会按一条可落地的路线来讲先说清楚 JMeter 的核心能力和硬件门槛再带你完成环境准备和安装启动接着用实际接口案例把接口测试、参数化、断言、Token 关联这些企业级常用操作过一遍然后进入性能测试环节讲线程组设计、聚合报告指标、分布式压测和服务端监控最后补充常见问题排查和工程化最佳实践。如果你正在准备测试岗面试或者刚转行测试开发这篇文章可以直接当作一份速查手册来读。关于标题里的“融合 AI”我也会在文末用一个章节专门展开。AI 在 JMeter 里的落地方式不是取代 JMeter而是帮你更快地生成测试数据、写断言表达式、分析压测报告和定位性能瓶颈。但有一点必须先说清楚公司内部接口的真实地址、Token、手机号、身份证这类数据不要直接粘贴到外部 AI 服务里脱敏之后再让 AI 干活这是边界问题。1. 核心能力速览开始动手之前先把 JMeter 的核心规格和适用边界放在一张表里。这样你判断要不要深入学一眼就能看明白。能力项说明项目类型Apache 开源测试工具Java 应用依赖 JVM 运行主要协议HTTP/HTTPS、WebSocket、JDBC、JMS、FTP、TCP、SMTP 等核心功能接口测试、性能测试、压力测试、分布式压测、自动化回归启动方式GUI 模式启动调试用、非 GUI 命令行模式压测用依赖环境JDK 8 及以上具体版本以 JMeter 官方支持矩阵为准硬件门槛单机小并发门槛很低4G 内存即可跑大并发建议独立压测机或分布式数据驱动支持 CSV 参数化、用户自定义变量、JDBC 数据源批量任务支持循环次数、调度器、非 GUI 批量执行、定时任务接入接口能力自带 HTTP 取样器、文件上传、Cookie 管理、HTTP 头管理、断言组件扩展能力插件管理器、JSR223(Groovy) 脚本、自定义 Java Sampler报告产出聚合报告、结果树、后端监听器非 GUI 模式可生成 HTML 报告适合场景接口回归测试、性能压测、CI/CD 集成、教学与面试准备从这张表可以提炼出三个结论。第一JMeter 的启动门槛不高只要装好 JDK解压即用。第二它不是一个“点一下按钮就出报告”的黑盒工具核心价值在于你能精确控制并发模型、参数化逻辑和断言规则。第三它的性能测试能力是单机和分布式结合的小项目单机跑大项目用 Master/Slave 模式横向扩展。2. 适用场景与使用边界JMeter 适合谁适合以下几类人刚入行的测试工程师需要建立接口测试和性能测试完整认知测试开发工程师需要把 JMeter 脚本接入 CI 流水线后端开发工程师想快速验证接口在并发下的表现以及准备性能测试岗位面试的同学需要掌握线程组、TPS、响应时间、聚合报告这些核心概念。它能解决什么问题最典型的是三类。第一类是接口回归测试把几十个接口的请求参数、预期结果、依赖关系固化到测试计划里每次代码变更后一键跑一遍。第二类是性能基准测试确认单个接口在给定并发下能打到多少 TPS、响应时间是否达标。第三类是稳定性验证用较长时间的中等并发去压测服务观察内存是否泄漏、连接池是否耗尽、GC 是否异常。也要说清楚它不适合什么。JMeter 不适合做复杂的前端 UI 自动化它模拟的是 HTTP 协议层的请求没法像 Selenium 或 Playwright 那样操作浏览器元素。JMeter 也不适合做精细的网络协议模拟比如要模拟弱网下的 TCP 乱序应该用专业网络模拟工具。还有一个容易踩的坑如果你只是为了调试单个接口Postman 或 Apifox 的效率比 JMeter 高JMeter 的优势在于“批量 压测 报告”这条链路而不是单请求调试。使用边界方面有两条必须强调。第一压测目标必须获得授权。生产环境压测要避开业务高峰最好在专用压测环境执行即使是测试环境也要确认版本和网络链路是否允许压测。第二测试数据要脱敏。JMeter 脚本里经常会写入手机号、邮箱、身份证等信息提交到代码仓库或交给外部 AI 分析之前必须做数据脱敏处理避免敏感信息泄露。3. 环境准备与前置条件JMeter 的环境准备非常简单核心只有两步安装 JDK下载 JMeter。第一步确认 JDK。JMeter 依赖 Java 运行环境版本兼容性上JDK 8 是长期稳定选择新版 JMeter 对更高版本 JDK 的支持也很好。安装后可以用下面的命令验证环境java -version如果输出中包含版本号比如openjdk version 1.8.0_xxx或更高版本说明 Java 环境可用。这里需要注意很多同学安装 JMeter 后双击启动脚本没反应八成是 JDK 没装好或者JAVA_HOME没配置。Windows 上建议在系统环境变量中新建JAVA_HOME指向 JDK 安装目录并保证PATH中包含%JAVA_HOME%\bin。第二步下载 JMeter。打开 Apache JMeter 官网选择.zip包下载即可Windows、macOS、Linux 都有对应版本。国内网络环境下如果官网下载慢也可以找官方镜像站。下载完成后解压目录名称类似apache-jmeter-5.x。解压后不需要安装直接进入bin目录操作。JMeter 目录结构里值得先认识的几个文件夹目录作用bin启动脚本、配置文件、测试计划模板lib核心依赖库第三方 jar 包放这里lib/ext插件扩展目录自定义插件和扩展组件放这里docs本地文档extras扩展脚本比如 Ant 集成相关文件report-templateHTML 报告模板如果后面需要安装插件比如阶梯加压线程组、JSON 断言增强组件可以在bin目录下拿到插件管理器Plugins Manager把插件管理器 jar 包放到lib/ext后重启 JMeter在 GUI 里搜索安装其他插件。插件机制是 JMeter 生态里非常重要的一部分但建议克制使用能通过内置组件解决的问题不要引入太多第三方依赖。4. 安装部署与启动方式JMeter 启动方式分 GUI 模式和非 GUI 模式。GUI 模式用于新建测试计划、调试脚本、查看结果非 GUI 模式用于实际压测和批量执行。Windows 下启动 GUI 很简单进入bin目录双击jmeter.bat或者打开命令行执行jar实际在 Windows 命令行里应该这样启动cd C:\apache-jmeter-5.x\bin jmeter.batLinux/macOS 下执行cd /opt/apache-jmeter-5.x/bin ./jmeter第一次启动会同时弹出 JMeter 的 GUI 窗口和一个黑底命令行窗口。注意不要关闭命令行窗口JMeter 进程依赖它运行。性能压测时推荐使用非 GUI 模式。下面这行命令是最常用的 JMeter 压测格式jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir参数含义参数作用-n非 GUI 模式运行-t指定测试计划文件路径-l指定采样结果输出文件 JTL-e执行结束后生成 HTML 报告-o指定 HTML 报告输出目录目录必须不存在或为空为了保证压测时 JMeter 自身拥有足够的内存可以调整bin目录下jmeter.bat或jmeter脚本里的堆内存参数。默认内存上限通常较小大规模压测时需要改常见配置set HEAP-Xms1g -Xmx1g set NEW-XX:NewSize256m -XX:MaxNewSize256m这里建议把-Xms和-Xmx设成同一个值避免运行时堆内存动态伸缩带来额外 GC 开销。压测机的内存越大能挤出越多资源给 JMeter 创建线程但线程数也不是无限增加的这一点会在资源占用章节详细说。5. 第一个接口测试脚本从零跑通一次请求安装启动做完接下来做一个最小可用的接口测试脚本。先用 GUI 模式把流程跑通再切到命令行批量执行。新建测试计划的操作路径打开 JMeter GUI在左侧测试计划上右键添加线程组然后在线程组上右键添加取样器里的 HTTP 请求再添加监听器里的查看结果树。这样三样东西组成了一个最小脚本。HTTP 请求里填什么假设要测试一个公开的 HTTP 演示接口可以这样配置字段值协议http服务器名称或 IP127.0.0.1 或测试环境地址端口号8080方法GET路径/api/user/info配置完成后点击工具栏上的绿色启动按钮然后打开查看结果树会看到请求记录。如果响应数据正常返回说明最简脚本已经通了。接下来加一个响应断言。右键 HTTP 请求添加断言中的响应断言。这里可以按文本内容匹配比如接口返回{code:0}时就设置“包含”模式匹配code:0或匹配状态码。如果接口返回不包含预期关键字断言就会失败这样脚本就有了基本的“通过/不通过”判断能力。JMeter 的脚本本质上是一个 JMX 文件用 XML 保存。GUI 操作保存后你可以在文本编辑器里看到完整的结构。这里给出一个 HTTP 取样器的核心片段做示意实际演练时建议还是用 GUI 生成HTTPSamplerProxy guiclassHttpTestSampleGui testclassHTTPSamplerProxy testname请求用户接口 stringProp nameHTTPSampler.domain127.0.0.1/stringProp stringProp nameHTTPSampler.port8080/stringProp stringProp nameHTTPSampler.path/api/user/info/stringProp stringProp nameHTTPSampler.methodGET/stringProp /HTTPSamplerProxy这类 XML 不建议手写除非你想做自动化生成测试计划的工具。实际使用中GUI 保存一次就能拿到完整正确的内容。跑通之后要养成一个习惯先用“单用户跑 1 分钟”验证脚本。线程组设置 1 个线程、循环次数不设、勾选调度器持续时间填 60 秒。如果单用户跑 1 分钟没有报错再逐步加大并发。这个习惯能避免把脚本配置错误混入压测结果是排查问题的基础检查项。6. 企业级接口测试实战关联、参数化、文件上传与断言单个接口跑通只是起点。企业级接口测试的现实是接口之间有依赖关系请求参数需要动态变化测试数据从 CSV 或数据库读取部分接口需要登录态还有文件上传、签名、分页、多环境切换等复杂场景。这一节把最常用的企业级组合讲透。6.1 接口关联Token 从上一个接口提取到下一个接口最常见的关联场景是登录后拿到 Token再携带 Token 请求业务接口。实现方式是在第一个接口后面添加正则表达式提取器或 JSON 提取器把响应中的 Token 存入变量。如果接口返回格式是 JSON比如{ code: 0, data: { token: abc123token } }可以在登录请求上右键添加后置处理器中的 JSON 提取器配置如下字段值变量名tokenJSON Path 表达式$.data.token默认值NOT_FOUND这样后续接口就可以在 HTTP 请求头的 Authorization 字段里引用${token}。如果是简单的响应字符串也可以用正则表达式提取器写法是token:(.*?)。JSON 提取器更直观推荐优先使用。6.2 CSV 参数化批量测试数据的标准做法性能测试和数据批量测试都离不开参数化。正路是把测试数据放到 CSV 文件里用 CSV 数据文件设置组件读取请求参数中用${变量名}引用。先用脚本生成一份 CSV 测试数据。以 Python 为例使用 Faker 库生成 100 条模拟用户数据from faker import Faker fake Faker([zh_CN]) with open(mock_users.csv, w, encodingutf-8) as f: f.write(username,phone\n) for _ in range(100): username fake.name() phone fake.phone_number() f.write(f{username},{phone}\n)然后在 JMeter 中添加配置元件里的 CSV 数据文件设置字段值文件名指向 mock_users.csv 的绝对路径或相对路径文件编码utf-8变量名称username, phone分隔符,是否循环读取True线程共享模式所有线程配置完成后HTTP 请求参数里把用户名写成${username}手机号写成${phone}每次请求就会从 CSV 文件中读取一行数据。批量任务就是这么跑起来的线程组启动多少线程就会消费多少行数据。6.3 文件上传与 Cookie 管理JMeter 支持文件上传。在 HTTP 请求的 Files Upload 标签页配置字段值文件名称本地文件绝对路径参数名称上传接口约定的字段名MIME 类型按文件类型填写比如 image/png如果是带登录态的上传接口还需要配合 HTTP Cookie 管理器或 HTTP 头管理器来携带 Session 或 Token。Cookie 管理器一般直接加到线程组下即可JMeter 会自动保存和发送当前线程上下文中的 Cookie。6.4 断言体系响应断言、时长断言、JSON 断言断言是让脚本具备自动判断能力的核心。常用的有三类第一类是响应断言匹配响应文本、响应代码、响应头适合校验接口返回值是否包含指定关键字。第二类是持续时间断言设置一个最大时间如果接口响应时间超过阈值断言失败适合做接口性能回归。第三类是 JSON 断言针对 JSON 响应做更精细的判断。实际项目中建议组合使用。比如新增用户接口既要判断返回码是 0又要判断响应时间小于 500ms还要判断数据库或 Redis 中是否出现预期数据。数据库层面的校验可以用 JDBC 取样器执行 SQL把查询结果与接口返回做逻辑判断。6.5 后端未就绪时的 Mock 联调企业级开发中经常出现“前端和测试等后端”的场景。这时的做法是用 Mock 工具临时模拟接口比如 WireMock、Apifox 的 Mock 功能或者直接用 JMeter 配合一个简易回显服务。Mock 的价值是让测试脚本开发和接口联调并行推进等真实接口就绪后再替换地址执行。需要提醒的是Mock 数据在进入 JMeter 脚本前要保持字段结构与真实接口一致否则后续参数化、断言和关联全都会返工。建议约定一份接口文档Mock 返回严格遵循文档字段。7. 性能测试实战线程组设计、指标解读与瓶颈定位接口测试通过后进入性能测试环节。这是 JMeter 的核心场景也是最容易把结果跑废的地方。7.1 线程组参数设计线程组是性能测试的入口有四个关键参数需要理解参数作用线程数模拟的并发用户数Ramp-Up Period启动全部线程所需时间单位秒循环次数每个线程执行脚本的次数调度器设置持续时间比如压 10 分钟一个基础实践是先用 10 并发压 1 分钟观察 TPS 和错误率再逐步提到 50、100、200。每次调整并发后先跑 1 到 3 分钟记录数据再继续增。不要一上来就压 500 并发因为服务可能直接被打挂你也分不清瓶颈到底在哪里。单用户 1 分钟验证是压测前必做的一步。确保 1 个线程、60 秒内没有报错后再上并发。这一步看起来简单但能过滤掉大量脚本本身的问题比如漏了断言、参数写死、CSV 路径错误。7.2 聚合报告指标怎么看压测结束后聚合报告会给出样本数、平均响应时间、中位数、90% 响应时间、最小最大响应时间、错误率、吞吐量。用一张表把核心指标说明白指标含义关注重点Samples采样请求总数数量太少则结果不具备参考性Average平均响应时间受极端值影响较大Median50% 请求的响应时间更能代表典型响应90% Line90% 请求在多少时间内完成判断长尾延迟Error%错误请求占比性能测试中直接决定是否通过Throughput每秒事务数 TPS系统吞吐能力核心指标判断一个接口是否达标不能只看平均值。比如平均响应时间 200ms但 90% Line 是 2 秒说明大量请求在慢速通道里。这时候需要看应用日志、慢 SQL 和 GC 日志来定位原因。7.3 压测曲线与瓶颈定位性能测试的目标不是“测出多少并发”而是找到系统的拐点。理想情况下随着并发增加TPS 线性上升当并发到达某个值后TPS 增长放缓甚至下降同时响应时间明显上升这个位置就是瓶颈点。瓶颈可能出在应用层、数据库层、网络层或者 JMeter 压测机自身。先确认压测机没有到极限再去看服务端。服务端监控建议至少覆盖四个维度监控维度常用工具系统层top、vmstat、free、iostat应用层应用日志、GC 日志、线程栈中间件Redis、MySQL、消息队列连接数网络层带宽、延迟、TCP 连接数压测过程中把聚合报告和服务端监控数据盯在一起才能定位瓶颈。比如 TPS 上不去但服务端 CPU 已经 90% 以上基本可以判断是应用计算逻辑或 GC 压力大如果服务端资源占用很低而 TPS 上不去就要考虑 JMeter 压测机是否线程数受限或者网络链路是否有带宽瓶颈。8. 分布式压测Master/Slave 模式单机压测在并发数较高时会出现瓶颈。JMeter 本身是 Java 进程线程数受 JVM 堆内存和操作系统线程数限制压测机自身 CPU 也会被采样、断言和结果处理消耗。这时候需要分布式压测。分布式压测的结构是一个 Master 和多个 Slave。Master 负责调度测试计划Slave 负责实际发送请求并回传结果。Slave 启动方式jmeter-serverMaster 执行压测时的命令与非 GUI 模式类似只需要加上远程主机配置jmeter -n -t test_plan.jmx -r -l result.jtl -e -o report_dir-r参数表示启动配置好的所有远程 Slave。分布式压测有几个常见坑第一测试计划中包含的 CSV 数据文件必须在每个 Slave 机器上都存在Master 不会自动同步文件。第二所有机器的 JMeter 版本、JDK 版本尽量保持一致避免脚本解析差异。第三Master 只负责调度和结果收集不要用 Master 发请求否则 Master 会成为瓶颈。第四Slave 主机的时区会影响报告时间展示建议统一时区。分布式压测不一定适合所有项目。如果单机就能打到目标 TPS就没有必要引入分布式避免增加环境复杂度和结果误差。9. 资源占用与性能观察JMeter 自身的资源占用直接影响压测结果这个点经常被忽略。启动 JMeter 时默认堆内存往往不够大压测过程中会出现频繁 GC、卡顿甚至 OOM。压测前先检查 JVM 参数。Windows 下在jmeter.bat中调整Linux/macOS 下在jmeter脚本中调整HEAP-Xms4g -Xmx4g NEW-XX:NewSize512m -XX:MaxNewSize512m具体分配多少取决于压测机内存。经验做法是堆内存不超过物理内存的一半剩余内存留给操作系统、GC、网络连接和采样结果处理。GUI 模式和监听器对资源的影响也很大。压测过程中如果打开查看结果树和聚合报告JMeter 需要把每个采样结果渲染到界面这会显著增加内存和 CPU 消耗。所以压测时一定要用非 GUI 模式监听器也要尽量少用。可以把采样结果写入 JTL 文件压测结束后再生成 HTML 报告。非 GUI 模式下观察压测机资源用top -H观察 GC 情况可以用 JDK 自带的jstat例如jstat -gcutil pid 1000如果压测机 CPU 已到 80% 以上且 GC 频繁说明 JMeter 自身先到瓶颈了。这时候优先考虑降低监听器开销、降低采样频率或者扩展分布式压测而不是继续增大线程数。10. 常见问题与排查方法以下是 JMeter 使用中最常遇到的一批问题每条都按“现象、原因、排查、解决”给出参考。问题现象可能原因排查方式解决方案双击jmeter.bat无窗口弹出JDK 未正确安装或 JAVA_HOME 未配置命令行执行java -version安装 JDK配置 JAVA_HOME 与 PATHGUI 启动速度很慢插件过多或 JDK 版本不兼容查看启动日志清理不常用插件升级或回退 JDK请求返回 301/302 跳转接口地址缺少重定向处理查看响应头 Location添加 HTTP 重定向或手动提取新地址中文响应乱码响应编码与 JMeter 默认编码不一致查看响应头 charset用后置处理器转换编码或调整采样器监听器编码响应断言失败断言文本与实际响应不完全匹配打开查看结果树看响应体改用正则或 JSON 断言注意空格和转义HTTPS 请求证书报错目标证书不是公共信任证书查看响应错误信息添加 HTTP 请求默认值导入证书或禁用证书校验压测 TPS 上不去单机线程数达到瓶颈或服务端瓶颈观察 JMeter 机和服务端资源调大 JVM 堆或转分布式压测分布式 slave 连不上防火墙拦截或端口未开放检查 1099 等端口的连通性放行端口统一版本号检查日志CSV 数据读取失败文件路径错误或编码不支持查看采样日志中的变量值使用绝对路径确保文件编码为 utf-8压测结果 JTL 文件过大采样量太大检查文件大小增加取样间隔用后置处理条件下采样清理历史文件排查的原则是按照“环境 → 脚本 → 数据 → 服务端”的顺序逐层缩小范围。不要一上来就怀疑 JMeter 自身有问题先确认脚本配置和数据文件路径是否正确再检查服务端日志和监控指标。11. 最佳实践与使用建议11.1 把 JMeter 脚本工程化JMeter 测试计划也要当代码管理。建议目录结构如下jmeter-project/ ├── test-plan/ │ ├── smoke.jmx │ └── stress.jmx ├── data/ │ └── mock_users.csv ├── lib/ # 额外 jar 包 ├── report/ └── result/ └── result.jtl脚本、数据、报告分开存放。测试计划用 Git 管理CSV 测试数据如果包含敏感信息则不允许提交到仓库使用脱敏数据占位真实数据由流水线在运行前注入。压测脚本中的环境地址不要写死。使用 JMeter 的用户定义变量配置环境信息把协议、域名、端口、超时时间集中管理。多环境切换时只需要改一组变量避免在脚本里全局替换。接口测试和性能测试要分开两个 JMX 文件。接口回归脚本偏重大量断言和数据关联性能压测脚本要尽量精简断言因为断言越多JMeter 自身的消耗越大也会影响压测数据的纯净度。11.2 融合 AI 的 Jmeter 测试实践标题里提到的“融合 AI”在实际落地中主要有四个具体方向。第一个方向是 AI 生成测试数据和参数化模板。用 Python 脚本配合 Faker 生成 CSV 是常规做法而 AI 的价值在于按业务规则更高效地生成边界值和组合条件。比如注册接口需要同时考虑用户名长度、特殊字符、重复注册、手机号格式等字段组合直接让 AI 生成一批边界用例是比较节省时间的方式。第二个方向是 AI 辅助编写正则表达式和 JSONPath 表达式。很多测试同学能完成接口请求但写提取器时经常卡住。把接口返回的关键片段传给 AI说明要提取哪个字段AI 能快速给出一版提取表达式你再拿到 JMeter 里验证。这里强调一遍提交给 AI 的内容必须先脱敏不能把真实 Token、手机号、接口内网地址直接发给外部服务。第三个方向是 AI 辅助分析压测报告。压测得到 JTL 和 HTML 报告后可以整理关键指标比如平均响应时间、90% 响应时间、错误率、TPS 走势让 AI 帮助梳理瓶颈假设和排查方向。AI 能给出检查清单式的建议但最终结论必须结合服务端日志和监控数据确认。第四个方向是 AI 辅助输出压测总结和接口测试报告。压测结束后把聚合报告数据整理成结构化描述让 AI 生成适合发送给团队的测试报告初稿再手动复核数据和结论。但要注意AI 不能代替对接口业务逻辑和系统架构的理解。把它当作生产力工具来用判断和决策责任仍然在你这边。涉及到线上流量、压测时间和系统变更时必须有明确的授权和变更流程。11.3 接口测试与性能测试的合规提醒不管是接口测试还是性能测试都要守住几条底线压测目标必须是得到授权的主机或服务。不要对不熟悉的公网地址做压力测试这类行为可能属于网络攻击后果很严重。测试数据要遵循最小化原则能用脱敏数据就不要使用真实用户数据。生产环境压测必须在业务低峰期进行并且要有回滚预案一旦发现服务异常要立即停止压测并通知相关负责人。使用 AI 服务辅助测试时要确认数据脱敏规则。涉及代码、日志、接口返回、业务数据时先检查是否包含敏感信息再决定是否提交给外部 AI 服务。企业内网如果部署了隔离的开发环境优先使用公司允许的内部 AI 服务或本地模型。12. 总结与下一步如果你现在只记三件事那就是第一JMeter 的完整链路是接口调试、参数化、断言、批量执行、性能压测、报告分析把它当成一整个体系来学不要只看单个功能。第二性能测试的起点是压测机自身要可靠脚本先单用户跑 1 分钟再逐步加压指标要综合分析不能只看平均值。第三AI 可以辅助生成测试数据、表达式、报告和瓶颈排查思路但所有涉及真实数据的内容必须先脱敏压测动作必须获得授权。这篇文章覆盖了从安装到分布式压测的完整路径但 JMeter 的能力远不止这些。后面可以继续深入的方向包括用 JSR223 Groovy 编写更复杂的校验逻辑把 JMeter 脚本接入 Jenkins 或 GitLab CI 做定时回归结合 Prometheus、Grafana 搭建性能监控大盘以及对比学习 Locust、k6 等不同压测工具理解它们之间的适用差异。建议先把文中的基础脚本自己动手搭一遍再拿一个真实接口做一次小并发压测。遇到问题就回到常见问题排查表逐项对照。把这套流程跑熟再去应对面试中的性能测试问题就有底气了。