全局变量滥用是内存泄漏最常见原因：未声明变量会自动挂载到window/global，长期驻留内存；修复须启用'use strict'、esm模块、eslint规则，并避免this指向window或with语句。
全局变量滥用是内存泄漏中最隐蔽也最常见的一类，它不依赖复杂逻辑，往往只因一行漏声明的代码就让大对象长期驻留内存。
为什么全局变量会导致泄漏
在非严格模式下，未用 var、let 或 const 声明的变量会自动挂载到 window（浏览器）或 global（Node.js）上。这些变量从页面加载起就存在，直到关闭标签页才释放——哪怕只调用一次函数，里面创建的数组、对象、DOM 节点都会被“钉死”在全局作用域里。
如何快速检测这类泄漏
打开 Chrome DevTools → Memory 面板 → 点击 Take heap snapshot，然后在快照中搜索 Window 或 Global 下的属性：
- 筛选类型为 Closure 或 Object，查看哪些属性名看起来像临时变量（如 dataCache、tempList、nodeRef）
- 点击该属性，在右侧 Retainers 中确认其路径是否为 window.xxx
- 配合 Allocation instrumentation on timeline 录制：触发疑似泄漏操作后，观察蓝色柱状图是否持续增长且不回落
修复方法要从源头堵住
不能靠事后清理，必须阻断产生路径：
- 全项目启用 'use strict'，让未声明变量直接报错，而不是静默挂全局
- 使用 ESM 模块（.mjs 或 type="module"），模块默认严格模式，天然免疫此类问题
- ESLint 配置 no-undef 和 no-unused-vars 规则，CI 流程中拦截上线
- 避免在控制台调试时随手写 obj = {...}，退出前执行 delete window.obj 或刷新页面
特殊情况也要注意
有些“伪全局”更难察觉：
- this 在非箭头函数中指向 window，this.cache = largeArray 等价于 window.cache = largeArray
- with 语句会动态扩展作用域链，可能意外污染全局，应禁用
- 第三方库若未用严格模式，也可能向 window 注入变量，可通过沙箱环境或模块化引入隔离
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
