防范隐式全局变量内存泄漏需三重策略：严格模式从执行时杜绝污染；ESLint/TypeScript在静态检查与编译时拦截；DevTools快照结合运行时扫描定位清理。
JavaScript 的垃圾回收本身不监控变量声明方式，但隐式全局变量会绕过作用域控制，长期驻留内存，成为典型的内存泄漏源头。防范关键不在“等 GC 回收”，而在于从编码阶段就阻断隐式全局的产生，并辅以工具验证。
严格模式是第一道防线
启用 "use strict" 后，未声明直接赋值（如 a = 10）或错误使用 this（如 this.b = 20）会立即抛出 ReferenceError，而非静默挂到 window 上。这从执行时就杜绝了污染。
- 在脚本顶部或函数体首行添加
"use strict" - 模块（
.mjs或type="module"）默认启用严格模式，无需手动加 - 避免混合使用：非严格函数内调用严格函数，不会影响外层作用域安全性
静态检查与构建时拦截
仅靠运行时严格模式不够——它不捕获所有场景（比如动态属性赋值 window[prop] = val），需借助工具提前发现。
- ESLint 配置
no-implicit-globals: error规则，检测未声明变量和顶层this赋值 - TypeScript 编译时开启
noImplicitAny和strict模式，强制显式声明，变量无定义即报错 - CI 流程中集成检查，禁止带隐式全局的代码合入主干
运行时辅助验证与兜底清理
对于遗留代码或第三方库引入的隐式全局，可主动扫描并标记/清理，但不可替代预防。
立即学习“Java免费学习笔记（深入）”；
- 页面加载后，快照
Object.keys(window)，后续定期比对新增属性，结合白名单过滤（如console,document） - 对确认无用的隐式变量，手动赋值为
null或undefined，帮助 GC 识别其不可达 - 注意：删除
window属性（delete window.xxx）在部分浏览器中无效或有副作用，赋值更稳妥
DevTools 内存快照定位问题
当怀疑存在隐式全局导致内存异常增长时，用 Chrome DevTools 直观确认：
- 打开 Memory 面板 → 点击 Take heap snapshot
- 切换到 Constructor 视图，筛选
Global Property或Object类型 - 按 Retained Size 排序，查看哪些属性占用大、无业务意义、命名随意（如
tempData,cacheObj） - 右键对应条目 → Reveal in Summary view，追溯其首次被赋值的位置
