全局变量滥用导致内存泄漏隐匿，因其不报错、不依赖dom或定时器、复现周期长且常规测试难发现；核心是挂载到window或globalthis使变量获“永生权”，长期驻留闭包链、缓存及已卸载组件状态。
全局变量滥用导致的内存泄漏之所以“隐匿”，是因为它不触发明显报错、不依赖 DOM 或定时器、复现周期长，且在常规测试中几乎不可见。问题核心在于：变量一旦挂到 window（浏览器）或 globalThis（通用）上，就等于获得与页面同寿命的“永生权”——哪怕只是一次误赋值，也可能让整个闭包链、大型缓存、已卸载组件状态长期驻留内存。
关键识别信号：从现象反推根源
当出现以下任意组合时，应立即怀疑全局变量滥用：
-
堆快照中 Closure 类型持续增长，且多数 retainers 显示为
window.xxx、globalThis.cache或某个模块级单例对象（如AppStore.instance） -
Detached DOM 数量稳定，但 JS 堆内存（
totalJSHeapSize）却阶梯式上升——说明泄漏与界面无关，是纯 JS 引用链锁定 -
组件销毁后仍可访问其私有数据：比如在控制台输入
window.debugHandler?.toString()，发现函数体里明确引用了this.state或props.bigList -
Node.js 环境下
process.memoryUsage().heapUsed持续上涨，且gc.get_count()显示 GC 频次未同步增加——说明对象未被回收，而非只是分配多
自动化扫描规范：三阶落地检查
不能依赖人工翻代码。需建立可执行、可集成、可审计的扫描机制：
-
静态层：ESLint 强制拦截
启用
no-implicit-globals（禁止隐式全局）、no-global-assign（禁止直接给window/globalThis赋值）、no-restricted-properties（禁用window.xxx = ...这类写法）；CI 流程中设为 error 级别，不通过即阻断合并 -
运行时层：启动期全局污染检测
在应用初始化前注入检测脚本，记录
Object.keys(globalThis)快照；加载完主逻辑后再次采集，比对新增属性。对非白名单属性（如__DEV__、APP_VERSION）自动告警并打印调用栈（console.trace()） -
内存层：MemLab 定期巡检
每日构建后自动生成堆快照，用 MemLab 的
GlobalVariableAnalysis插件分析；输出报告必须包含：变量名、Retained Size、首次出现 commit、引用路径深度、是否含闭包捕获大对象（如Array(1e5)、JSON.stringify(...)）
高频误操作清单与替代写法
这些写法在开发中看似自然，实则高危：
-
错误：
function init() { const data = fetchBigConfig(); window.onReady = () => render(data); }→data被闭包捕获，window.onReady让它永不释放 修复：改用参数传递 + 显式清理：window.onReady = (config) => render(config); window.onReady(data); delete window.onReady; -
错误：
userCache = new Map(); // 缺少 let/const→ 隐式挂到window.userCache，随页面存活 修复：严格模式 + 显式声明："use strict"; const userCache = new Map(); -
错误：
globalThis.tempResult = response.data;（用于调试后忘记删） 修复：统一用临时调试命名空间 + 自动过期：globalThis.__DEBUG__ = { tempResult: response.data, expiresAt: Date.now() + 60_000 };，配合定时清理脚本
这类泄漏不会报错，也不会卡顿，只会让服务越跑越重、GC 越来越频繁、重启间隔越来越短。早建扫描规范，比等 OOM 杀进程再查快十倍。
