页面卡顿、响应变慢、频繁GC或内存持续攀升是JavaScript内存泄漏的明确前兆；应通过Memory面板观察JS Heap阶梯式上升、Nodes/Liseners只增不减，结合堆快照对比定位未释放对象，并按闭包、全局引用、大数组等高频模式静态拦截。
当控制台还没报 JavaScript heap out of memory，但页面已开始卡顿、响应变慢、频繁 GC（垃圾回收）或内存使用持续攀升——这些就是明确的前兆。预防的关键不是等崩溃，而是提前观察、定位、干预。
看懂内存曲线的异常信号
在 Chrome DevTools 的 Memory 面板中录制一段典型操作（如打开页面→交互→离开），重点关注三条线：
- JS Heap：正常应呈“锯齿状”——每次 GC 后回落；若回落不明显、或每次峰值都比前一次高，说明对象未被回收
- Nodes：DOM 节点数持续上涨且不回落，大概率存在未卸载的事件监听器或未销毁的组件引用
- Listeners：监听器数量只增不减，尤其在单页应用路由切换后仍居高不下，是泄漏强信号
用堆快照对比定位“长生不老”的对象
不要只拍一张快照。按标准流程操作：
- 启动页面，等待稳定 → 拍摄 Snapshot 1
- 执行疑似泄漏的操作（如打开弹窗、加载列表、切换 tab）→ 拍摄 Snapshot 2
- 执行清理动作（关闭弹窗、清空列表、返回首页）→ 等待 5–10 秒 → 拍摄 Snapshot 3
切换到 Comparison 视图，筛选 Objects allocated between Snapshot 1 and 2，再按 Retained Size 降序排列。重点排查：
— 大量重复出现的闭包（Closure）、
— 引用链中包含 document 或 window 的对象、
— 类似 Array / Object 占用数百 MB 且无法被释放的实例。
监控运行时内存水位，设置主动告警
在开发或测试环境加入轻量级内存巡检逻辑，比如：
function checkHeapUsage() {
const { heapUsed, heapTotal } = process.memoryUsage?.() || {};
if (heapUsed && heapTotal) {
const usage = (heapUsed / heapTotal * 100).toFixed(1);
if (usage > 75) console.warn(`⚠️ 内存使用 ${usage}%，接近阈值`);
}
}
setInterval(checkHeapUsage, 5000);配合 CI 构建阶段跑内存敏感用例（如批量渲染 1000 条数据后强制 GC），用 process.memoryUsage() 断言堆使用是否回落至合理区间。
识别三类高频泄漏模式并静态拦截
很多泄漏在写代码时就已埋下，可在 ESLint 或自定义检查工具中加规则提前拦截：
-
定时器未清理：检测
setInterval/setTimeout赋值给变量，但无对应clearInterval/clearTimeout -
事件监听器未解绑：检测
addEventListener后缺少removeEventListener，尤其在组件destroyed或useEffect cleanup中缺失 -
全局/模块级大对象缓存：检测
window.xxx = bigData或export const cache = new Map()且未设淘汰策略（如 LRU）
