稳定性测试是很多团队容易忽略的环节。功能测试关注的是单次操作是否正确，而稳定性测试关注的是应用在数小时甚至数天的连续运行中，是否会出现内存持续增长、响应变慢直至标签页崩溃的情况。React应用由于组件生命周期的存在，泄漏往往不是一次性的，而是随着组件挂载卸载不断累积，短时间测试很难发现。本文从泄漏成因、检测工具和自动化方案三个层面，完整讲一遍如何在React项目中落地稳定性测试。
React应用内存泄漏的常见成因
React应用里最常见的泄漏源是副作用没有清理。当一个组件挂载时注册了定时器、事件监听器或订阅，卸载时却没有释放，这些回调持有的闭包会连同组件内部的所有state一起被钉在内存里。下面这段代码就是一个典型反面教材：
function ChatPanel({ roomId }) {
const [messages, setMessages] = useState([]);
useEffect(() => {
// 错误示范：只订阅，从不清理
const timer = setInterval(() => {
fetchMessages(roomId).then(setMessages);
}, 1000);
window.addEventListener('resize', handleResize);
socket.on('message', handleMessage);
}, [roomId]);
}
每次roomId变化或组件卸载，旧的interval、resize监听和socket订阅都不会被移除。如果用户在路由间来回切换，每切一次就多挂一份，堆内存呈阶梯状上涨。正确做法是让Effect返回清理函数：
useEffect(() => {
const timer = setInterval(() => {
fetchMessages(roomId).then(setMessages);
}, 1000);
window.addEventListener('resize', handleResize);
socket.on('message', handleMessage);
// 清理函数：依赖变化或组件卸载时执行
return () => {
clearInterval(timer);
window.removeEventListener('resize', handleResize);
socket.off('message', handleMessage);
};
}, [roomId]);
除了Effect清理缺失，还有几类高频问题：全局Map或数组持续追加数据却从不裁剪，比如日志缓存、消息列表不设上限；被卸载组件的引用被外部单例持有，例如某个全局store存了组件回调；老版本Redux中store.subscribe的返回函数被丢弃；以及图片、Blob对象URL调用URL.createObjectURL后忘记revokeObjectURL。排查时优先检查这些位置。
用Chrome DevTools定位泄漏源头
定位泄漏最直接的工具是Memory面板的堆快照对比功能。操作步骤是：先执行一轮标准操作（比如打开再关闭目标组件十次），拍第一张快照；再重复同样操作十次，拍第二张快照；然后在第二张快照的过滤框里选择Comparison视图，对比两个快照的差异。如果某个构造函数的实例数量随操作次数线性增长，基本可以锁定泄漏对象。
快照适合看累积结果，Allocation Timeline则适合看泄漏发生的瞬间。在Memory面板勾选Allocation instrumentation on timeline后录制，蓝色柱表示仍在内存中的对象，灰色柱表示已被GC回收。反复执行可疑操作时，如果蓝色柱持续堆积而不转灰，说明这些分配被引用着，点击柱子就能看到保留链（Retainers），顺着链条通常能找到那个忘记解绑的监听器或缓存。
还有一个更轻量的日常手段：Performance监视器。打开DevTools后按Ctrl+Shift+P输入performance monitor，勾选JS Heap Size和DOM Nodes。让页面静置半小时，正常情况下堆大小应该呈锯齿状波动（GC在工作），如果整体趋势持续爬升，DOM节点数也只增不减，说明存在泄漏。这个方法不需要截图对比，肉眼观察趋势即可，适合作为稳定性测试的第一道筛查。
搭建长时间运行的自动化稳定性测试
人工盯监控不现实，长时间测试必须自动化。思路是用Puppeteer（或Playwright）驱动浏览器执行真实交互，同时定期采集堆内存和DOM节点数，绘制曲线并判断是否超阈值。下面是一个可以直接改造的脚本骨架：
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({ headless: false });
const page = await browser.newPage();
await page.goto('http://192.168.0.1:3000/dashboard');
const samples = [];
for (let i = 0; i < 720; i++) { // 每5秒一轮，共1小时
// 模拟用户来回切换路由，触发组件挂载卸载
await page.click('[data-testid="nav-settings"]');
await page.waitForTimeout(500);
await page.click('[data-testid="nav-dashboard"]');
await page.waitForTimeout(500);
// 通过CDP采集堆大小
const metrics = await page.metrics();
samples.push({
time: Date.now(),
heapMB: (metrics.JSHeapUsedSize / 1024 / 1024).toFixed(1),
nodes: metrics.Nodes,
});
await page.waitForTimeout(4000);
}
// 简单判断：后半段均值比前半段高出30%即认为可疑
const half = samples.length / 2;
const avg = arr => arr.reduce((s, x) => s + +x.heapMB, 0) / arr.length;
const growth = avg(samples.slice(half)) / avg(samples.slice(0, half));
console.log(`堆内存增长比例: ${(growth * 100).toFixed(1)}%`);
if (growth > 1.3) {
console.error('检测到疑似内存泄漏，需要人工排查');
process.exitCode = 1;
}
await browser.close();
})();
page.metrics()返回的指标中，JSHeapUsedSize反映JS堆占用，Nodes反映DOM节点数，两者配合足以覆盖绝大多数泄漏形态。判断阈值建议用前后半段对比而不是绝对值，因为不同应用基线差异很大。如果测试时长拉到数小时，可以把采样间隔放大，并在脚本里加入随机操作（滚动、输入、打开弹窗），让交互更接近真实用户行为，避免只测到单一固定路径。
崩溃检测方面，除了内存指标，还要关注页面的unhandledrejection和error事件。可以在页面初始化时注册监听，把错误上报到测试日志，一旦出现连续报错或标签页自动关闭（Puppeteer会抛出Target closed异常），立即保留现场截图与堆快照，方便事后分析。团队实践中，把这套脚本接入CI做夜间定时任务，第二天早上看报告，是性价比很高的做法。
预防胜于检测：日常编码规范建议
稳定性问题最好在代码评审阶段就拦住。几条值得固化为规范的规则：所有用到定时器、事件监听、socket订阅的Effect必须写清理函数；消息列表、日志缓存这类无限增长的数据结构设置上限并淘汰旧数据；避免在模块顶层保存组件实例或回调；使用URL.createObjectURL时配对调用revoke。另外可以引入ESLint的react-hooks/exhaustive-deps规则，它虽然主要检查依赖数组，但能迫使开发者认真审视每个Effect的生命周期。
在测试环境开启React StrictMode也有帮助。StrictMode会在开发模式下故意双次挂载组件，如果清理函数写得不对，开发阶段就能立刻看到重复注册的告警，把问题消灭在编码时，而不是等线上跑了八小时之后才暴露。稳定性测试的最终目标不是发现泄漏，而是让泄漏根本不进入主干。
React内存泄漏稳定性测试Performance监控修改时间：2026-09-11 12:12:40