压力测试的目的不是证明应用能跑，而是找出它在什么条件下跑不动。一个React应用在开发环境里表现完美，不代表它能在高并发、大数据量、快速交互的场景下撑住。很多线上事故的根因，其实早在压测阶段就能暴露出来。这篇文章会从指标选择、工具搭建、瓶颈定位到优化落地，完整讲一遍React应用压力测试的实操流程。
一、先明确：React应用要压测什么
很多人把压力测试简单等同于接口压测，拿JMeter对着后端一顿猛打就算完事。但React应用的性能瓶颈往往是双重的：一部分在服务端吞吐，另一部分在浏览器端本身。前者决定了用户等待多久，后者决定了页面会不会卡死。
具体来说，React应用的压力测试要关注四类指标。第一是首屏时间和可交互时间（TTI），也就是从用户输入网址到页面真正能响应操作需要多久。第二是并发下的接口表现，包括P95、P99响应时间，这需要区分是后端慢还是前端请求队列堆积。第三是内存占用，长时间运行的单页应用如果存在内存泄漏，压测半小时后就会出现明显的卡顿。第四是渲染性能，比如一个几千条数据的表格，快速滚动或频繁筛选时是否掉帧。
崩溃临界点通常不是单一指标决定的，而是多个因素叠加的结果。比如接口响应从200ms恶化到2秒，同时用户还在疯狂点击按钮触发重复请求，React的状态更新队列就会堆积，主线程被长期占用，最终表现为页面无响应。压测的价值就在于用可控的方式复现这种叠加场景。
二、用k6模拟真实用户负载
k6是目前前端团队用得比较多的负载测试工具，它用JavaScript编写测试脚本，能够模拟真实用户的行为路径，而不只是机械地重复同一个请求。这一点对React应用尤其重要，因为SPA的接口调用是有时序依赖的：先拿token，再拉列表，再查详情，如果压测脚本把这些顺序打乱，测出来的数据和真实场景差距会很大。
下面是一个模拟用户登录并浏览列表的k6脚本示例：
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 }, // 2分钟内爬升到50个虚拟用户
{ duration: '5m', target: 50 }, // 稳定压测5分钟
{ duration: '2m', target: 200 }, // 继续加压到200，寻找临界点
{ duration: '1m', target: 0 }, // 逐步降压
],
thresholds: {
// 超过这条线就判定测试失败，这就是你定义的临界点
http_req_duration: ['p(95)<800'],
},
};
export default function () {
const loginRes = http.post('https://your-api.ipipp.com/login', JSON.stringify({
user: 'test',
password: '123456',
}), { headers: { 'Content-Type': 'application/json' } });
check(loginRes, { '登录成功': (r) => r.status === 200 });
const listRes = http.get('https://your-api.ipipp.com/items?page=1&size=50');
check(listRes, { '列表加载成功': (r) => r.json().code === 0 });
sleep(1); // 模拟用户阅读页面的停留时间
}
这个脚本的关键在于stages配置，它采用阶梯式加压的策略，从50用户逐步拉到200用户，观察每个阶段的P95响应时间。当响应时间开始非线性恶化，比如用户数从150涨到180，响应时间却翻了一倍，这个拐点附近就是系统的临界区间。thresholds则相当于给临界点画了一条红线，压测报告会直接告诉你有没有越线。
除了k6，Artillery也是不错的选择，它的YAML配置对非开发人员更友好。如果团队已经在用CI/CD流水线，建议把k6脚本纳入每次发布前的检查项，用固定的用户量做回归压测，防止某次改动悄悄把性能拖垮。
三、压测时如何定位浏览器端的瓶颈
接口压测只能证明数据供给没问题，浏览器端是否卡顿需要另外的手段。Chrome DevTools的Performance面板是第一选择：在压测进行中录制一段性能追踪，重点看主线程的Long Task，也就是超过50毫ksom秒的长任务。React的重渲染、大列表的同步DOM更新、复杂的计算逻辑，都会以长任务的形式暴露出来。
具体操作步骤是：打开Performance面板，勾选CPU降速为4倍慢速模式模拟低端设备，点击录制后快速执行滚动、筛选、切换路由等操作，停止后分析火焰图。如果看到大量连续的黄色Scripting块，且调用栈指向commitWork或performWorkUntilDeadline这类React内部函数，说明瓶颈在组件渲染环节，而不是接口。
React DevTools的Profiler则能精确到组件级别。开启录制后它会高亮每次提交中哪些组件发生了重渲染以及耗时多少。常见的问题是某个输入框每敲一个字符，整棵子树都跟着渲染，这时候就要检查memo、useMemo、useCallback是否用到位，或者状态是否放错了层级——把高频变化的状态下沉到叶子组件，往往比到处套memo更有效。
内存方面，用Memory面板做堆快照对比：压测开始前拍一次快照，运行三十分钟后再拍一次，对比两份快照中Detached DOM节点和闭包引用的增长情况。如果Detached节点持续增长，大概率是组件卸载后没有清理定时器、事件监听或全局订阅，这种泄漏在压测时长不够时根本发现不了。
四、找到瓶颈后的优化手段
压测暴露问题只是第一步，能不能把临界点往后推才是关键。针对渲染瓶颈，最经典的是虚拟列表方案。当列表条目超过几百条时，与其让React渲染全部DOM，不如只渲染视口内的几十条：
import { FixedSizeList } from 'react-window';
function BigList({ items }) {
return (
<FixedSizeList
height={600}
itemCount={items.length}
itemSize={48}
width="100%"
>
{({ index, style }) => (
<div style={style}>{items[index].name}</div>
)}
</FixedSizeList>
);
}
对于无法虚拟化的场景，比如树形结构或异构布局，可以用分片渲染的思路，把大批量任务拆成小块，通过requestIdleCallback或React 18的startTransition让高优先级的用户输入先处理，低优先级的渲染分批完成。并发特性中的useDeferredValue也很实用，它让搜索框输入保持即时响应，而结果列表的更新自动降级为可中断的低优先级任务。
请求层面，高频交互触发的接口调用一定要做防抖和请求取消。用AbortController在用户连续输入时取消上一次未完成的请求，避免响应乱序覆盖新数据，同时减少服务端的无效压力。数据缓存可以用React Query这类库，它的去重和缓存机制天然能抗住重复触发。
最后要强调一点：优化应该由压测数据驱动，而不是凭感觉。每次优化后重跑同样的k6脚本，对比P95、TTI和长任务数量的变化，确认临界点确实后移了再合入代码。没有度量闭环的性能优化，很容易变成自我感动的代码改动。把压测常态化，让每个版本都有性能基线，才能真正守住应用的可用性底线。