这是很多刚开始做接口压测的人都会遇到的问题Jmeter压测时怎样设置才能只登录一次然后集中精力去压测其他接口。我见过最典型的错误就是把登录请求和业务接口放在同一个循环里循环次数调成1000结果一个压测跑下来登录接口被执行了1000次而业务接口的数据被登录的耗时严重稀释。用这种方案跑出来的报告压根没法解释清楚“这个接口在并发下到底行不行”。先别急着改测试计划我们得先搞明白登录请求在你的压测方案里到底应该扮演什么角色。1. 把登录请求放进主循环等于白测先理解登录和业务请求的边界1.1 一个典型的错误示范我见过很多同事刚上手Jmeter时写出来的测试计划长这样线程组里放一个登录请求下面跟着要压制的列表接口设置100个线程、循环100次。表面上看很合理模拟了“用户登录后查询列表”的完整链路但实际上问题很大。跑完一看报告登录接口总共执行了10000次列表接口也执行了10000次但登录接口单次响应可能300ms列表接口只要20ms最终报告里登录接口的耗时占据了绝对大头列表接口的真实性能完全看不出来。更麻烦的是登录接口在大量并发下经常触发风控策略比如验证码校验、账号锁定、短信下发频率限制一旦某个线程登录失败后续业务请求全部跟着401。你本来想压测列表接口结果整个压测被登录接口搞崩了甚至连压测报告都拿不出来。这不是个别现象是新手最容易踩的第一个坑。所以做压测之前必须先把登录请求从主业务循环里摘出来。1.2 登录在压测模型里是“准备动作”不是被测对象在真实用户行为里登录是一次性成本。用户登录之后会在一个会话内执行大量操作查询列表、查看详情、下单、支付、退出。登录只是拿到身份凭证的敲门砖真正要压测的是敲门之后那些高频业务接口。如果你把登录请求塞进每个迭代就等于把登录接口的响应时间、资源消耗、风控逻辑全算进了业务接口的压测结果里。这就像测试一个超市收银台的吞吐量你不会让每个顾客先注册会员、充值再结算因为你关心的是收银台本身的处理能力而不是会员注册环节。登录接口本身往往很昂贵密码加密、用户校验、token签发、日志审计、安全风控每一步都有开销。把这种高成本请求放到高频循环里会彻底掩盖业务接口的真实表现。1.3 两种“只登录一次”的业务语义“只登录一次”这个需求实际分两种情况很多人一开始没分清导致后面怎么做都不对。场景A全局只要一个token。适合单账号、接口不区分用户、并发模型不需要每个用户独立身份的场景。比如压测一个公共查询接口所有并发都共用同一个登录后的token此时整个测试计划只需要登录一次。场景B每个虚拟用户一个token。适合模拟真实多用户每个用户有独立的账号、权限、数据隔离。此时每个线程启动时需要登录一次但同一个线程的后续迭代不再重复登录。维度全局单token每用户独立token适用场景单账号、共享查询接口多用户、用户数据隔离实现方式setUp线程组 属性共享仅一次控制器 CSV参数化并发模型所有线程共用身份线程和账号一一对应优点简单、登录成本最低更接近真实业务缺点无法区分单个用户登录次数随并发数增加搞清楚你是哪种场景后面的方案才有意义。接下来从最核心的环节说起登录之后怎么拿到token。2. 从登录响应里拿到TokenJson提取器和正则提取器的配置细节2.1 先确认登录接口返回了什么很多人在配置提取器之前根本没有仔细看过登录接口的响应体长什么样直接照抄网上的正则表达式结果折腾半天也提取不到。正确做法是先不加任何后置处理器只跑一次登录请求打开查看结果树看响应数据。常见的情况有三种响应体是JSON比如{code:0,data:{token:eyJhbGciOi...}}token在响应头里比如Authorization: Bearer eyJhbGciOi...或者Set-Cookie: sidxxxxx响应体是纯文本或HTML需要用正则去抠只有确认了返回格式才能决定用JSON提取器还是正则提取器。这一步花不了两分钟但能省后面几十倍排查时间。2.2 JSON提取器的配置项逐个说如果登录接口返回的是标准JSON直接用JSON提取器JSON Extractor。添加路径右键登录请求 - Add - Post Processors - JSON Extractor。需要关注的配置项Name of created variables创建的变量名比如填loginToken