内存泄漏主因是闭包和事件监听在组件卸载后仍强引用DOM、大对象等，导致GC无法回收；需严格配对绑定/移除监听器、避免匿名函数、精简闭包捕获、及时清理定时器与缓存，并用Chrome Memory面板定位泄漏源。
闭包和事件监听本身不是问题，真正引发内存泄漏的是它们“不该持有时还在持有”——比如组件卸载后，闭包仍强引用着 DOM 节点、大数组或整个实例，而事件监听又没解绑，导致整条引用链无法被垃圾回收（GC）。
事件监听器必须成对管理
绑定和移除要严格对应，尤其在组件生命周期结束时（如 React 的 useEffect cleanup、Vue 的 beforeUnmount 或原生的 removeChild 前）：
- 避免匿名函数绑定：
el.addEventListener('click', () => {...})会导致无法精准removeEventListener；改用具名函数或箭头函数变量 - 使用
{ once: true }处理一次性事件，自动清理 - 在单页应用中，路由跳转或弹窗关闭时，检查是否遗漏了
removeEventListener调用，特别是异步回调、条件分支或 try-catch 中的路径
闭包里只捕获真正需要的数据
不要让闭包“顺手带上”整个作用域。例如，配置对象很大，但回调只用其中 id 字段：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- ❌ 错误写法：
return () => console.log(config)—— 整个config被闭包持有 - ✅ 正确写法：
const id = config.id; return () => console.log(id)—— 只保留必要字段 - 对 DOM 元素、响应式数据、大型缓存等敏感对象，优先提取 ID、字符串或原始值，而非直接引用对象本身
定时器与缓存类闭包要主动销毁
这两类常和事件监听、闭包耦合，是泄漏高发区：
- 所有
setInterval必须保存返回的 timer ID，并在不再需要时调用clearInterval；推荐封装为可取消的结构，比如const timer = setInterval(...); return () => clearInterval(timer) - 用
Map或普通对象做缓存时，加容量限制（如 LRU 最大 100 条）和过期机制；避免无节制增长 - 缓存键若涉及闭包，优先用
WeakMap存储实例级映射，它能随目标对象被 GC 自动清理
用 Chrome Memory 面板定位真实泄漏点
别猜，要验证：
- 操作前先点垃圾回收图标（?），再拍 Heap Snapshot；重复触发疑似泄漏动作（如打开/关闭模态框）后，再拍一次
- 切换到 Comparison 视图，筛选 Closure 类型，看 “# New” 是否持续增加
- 点开可疑 Closure，右侧查看 “Retainers” —— 如果显示被
window、全局 Map、未清除的setInterval或长期存在的监听器引用，就确认是生命周期失控 - 重点关注它捕获的变量：如
document.getElementById(...)、hugeArray、VueComponent等明显的大对象或 DOM 节点
