DOM 元素被移除后，绑定其上的 addEventListener 依然存活 —— 组件卸载时忘记调用 removeEventListener()。
未清理的 setTimeout() / setInterval()，是本次分析中占比最大的单一泄漏来源。
已从页面移除的节点仍被 JS 变量、闭包或全局对象持有 —— 在 DevTools 中表现为 Detached 节点。
没有上限的内存缓存，以及路由懒加载后未释放的残留模块代码。
这四类里，前两类靠 code review 就能发现一部分，后两类几乎只能靠观测。
## Soak Test 是怎么跑起来的
1. **预热** —— 先执行 5 次完整流程，避开首次加载、字体加载、懒加载 chunk 带来的噪音，然后记录基线指标。
2. **循环 200 次** —— 在单一浏览器上下文中反复执行同一段往返操作，例如开关抽屉。
3. **两次 GC 后采样** —— 通过 CDP 的 `HeapProfiler.collectGarbage` 强制回收两次，再读取 Performance 指标。两次是为了让第一次回收释放出的对象所持有的引用也能被回收。
4. **断言** —— 监听器数应 ≤ 基线；节点数增长应小于一个**固定阈值**（如 +100），而不是按百分比放宽。
> [!TIP] 为什么阈值要用固定值而不是百分比
> 百分比阈值会随基线一起变大：一个初始节点数很多的页面，允许的增长空间也更大，反而更容易漏掉真实泄漏。固定阈值对所有页面一视同仁。
## 断言长什么样
```ts
// dashboard.spec.ts
test('the dashboard drawer does not leak', async ({ page }) => {
await page.goto('/dashboard');
// 200 次循环，其中前 5 次为预热
const { baseline, after } = await soak(page, () =>
openAndCloseDrawer(page)
);
// 监听器不应比基线更多
expect(after.listeners).toBeLessThanOrEqual(baseline.listeners);
// 节点增长用固定阈值，而不是百分比
expect(after.nodes).toBeLessThan(baseline.nodes + 100);
});
```
采样部分需要走 CDP，大致是这个形状：
```ts
const cdp = await page.context().newCDPSession(page);
async function sample() {
// 连续两次强制 GC，再读取指标
await cdp.send('HeapProfiler.collectGarbage');
await cdp.send('HeapProfiler.collectGarbage');
const { metrics } = await cdp.send('Performance.getMetrics');
const get = (name: string) => metrics.find((m) => m.name === name)?.value ?? 0;
return { nodes: get('Nodes'), listeners: get('JSEventListeners') };
}
```
## 让 200 次循环等于真实的 100 分钟
这里有个容易被忽略的陷阱：200 次循环两分钟内就能跑完，但一个 30 秒轮询一次的定时器，在这两分钟里只会触发 4 次 —— 远低于用户真实使用 1 小时里的 120 次。也就是说，**跑得快本身会掩盖泄漏**。
解决办法是把时间「拨快」：
- **虚拟时钟**：`page.clock.install()` 接管时间，每次循环后用 `runFor(18_000)` 手动推进 18 秒，让轮询定时器如期触发。200 次 × 18 秒 ≈ 覆盖真实使用 **约 100 分钟**。
- **网络模拟**：用 `page.route()` + `route.fulfill()` 返回与真实接口体量相当的响应，避免真实网络延迟拖慢循环，同时保留泄漏真正的触发条件（响应体大小、字段结构都要接近真实，否则测不出与数据量相关的泄漏）。
## 什么值得测，什么不用测
判断标准很简单：这段操作结束后，状态**是否应当**回到原点。应当回到原点却没回去，就是泄漏；本来就该留下东西，那测了也只是白报警。