该项目构建可观察、可对比、可验证的内存泄漏闭环环境，覆盖闭包引用、dom监听器未解绑、定时器隐式持有、全局变量污染四类典型场景，并集成观测、修复、自动化防护全流程。
JS 内存泄漏综合实战演练项目，核心不是写一堆“会泄漏”的代码再修掉，而是构建一个可观察、可对比、可验证的闭环环境——让你在真实操作中建立对泄漏发生机制、检测路径和修复逻辑的肌肉记忆。
搭建可复现的泄漏场景
从最典型、最高发的四类泄漏入手，每个场景单独封装、独立运行，避免干扰：
-
闭包引用大对象：用
createLeak()返回一个闭包，内部持有百万级数组；调用后保留函数引用，观察堆内存阶梯式上涨 -
DOM 监听器未解绑：动态创建按钮并绑定
click事件，随后移除按钮但不调用removeEventListener；反复执行后检查 DOM 节点残留与关联数据 -
定时器隐式持有上下文：在组件初始化时启动
setInterval，回调中引用了整个this或大型配置对象；组件销毁后未clearInterval -
全局变量污染：故意漏写
let/const，让cache = new Map()挂到window（浏览器）或global（Node.js），持续写入不清理
嵌入标准化观测手段
每个场景都配套三类观测点，确保问题“看得见”：
- 用
performance.memory（浏览器）或process.memoryUsage()（Node.js）每秒打印内存趋势，记录关键节点数值 - 在 Chrome DevTools 中手动触发三次堆快照（Heap Snapshot）：初始态 → 执行泄漏操作 5 次后 → 再执行 5 次后；用“Comparison”视图筛选
Retained Size增长最明显的构造器 - 在代码关键路径插入
console.timeStamp('leak-step-1')，配合 Performance 面板定位 GC 高频区段
设计验证性修复与回归测试
修复不是“加一行 null”，而是带验证逻辑的完整动作：
- 闭包泄漏：改用
WeakRef包裹大对象，或在闭包执行后显式置空引用，并在下一次快照中确认该对象已不可达 - DOM 泄漏：用
addEventListener的第三个参数{ once: true }，或封装on()/off()方法，销毁时自动解绑 - 定时器泄漏：把 timer ID 存入实例属性，
destroy()中统一clearInterval，并断言this.timerId === undefined - 全局泄漏：启用 ESLint 规则
no-implicit-globals，CI 阶段拦截未声明变量；本地运行时加一层if (typeof window !== 'undefined') { delete window.cache }强制清理
加入自动化防护层
演练最后一步，是把经验固化为工程能力：
- 在项目中集成
CoBOT SAST，配置 JS 内存泄漏规则集，让它在 PR 提交时自动标出Potential memory leak告警 - 为 Node.js 服务添加
--max-old-space-size=512启动参数，并配合process.on('warning', ...)捕获MaxListenersExceededWarning类内存预警 - 编写一个简易的
leak-checker.js脚本：启动服务 → 自动发起 100 次模拟请求 → 抓取前后堆快照 → 输出差异报告，作为每日 CI 任务
这个演练项目做完，你手上就不再是一堆零散技巧，而是一个可复用的泄漏响应手册：知道什么现象对应什么类型、该抓哪几个快照、怎么写修复才真正生效、以及如何让系统替你盯住下一次。
