全局变量因始终可达而无法被垃圾回收，导致内存长期泄漏；应通过严格模式、ESLint规则、集中管理及显式解绑来预防和修复。
全局变量是 JavaScript 中最隐蔽也最容易被忽视的内存占用源头。它们一旦创建，就会挂载在 window（浏览器）或 globalThis（通用环境）上，整个页面生命周期内都不会被垃圾回收器释放——哪怕只是一次误操作，也可能长期锁住几 MB 甚至几十 MB 的内存。
为什么全局变量会卡住内存
JavaScript 垃圾回收基于“可达性”：只要一个对象能从根对象（如 window、当前执行栈）被访问到，就不会被回收。而全局变量天然属于 window 的属性，始终“可达”。比如：
- 函数内漏写
let/const，直接赋值：data = new Array(1e6).fill(0)→ 等价于window.data = ... - 构造函数中错误使用
this：function A() { this.cache = bigObj }，若调用时忘了new，this指向window，cache就成了全局引用 - 模块顶层未声明的变量（尤其在非模块脚本中）也会污染全局
快速定位全局变量泄漏
不用猜，用 Chrome DevTools 直接查：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 打开 Memory 面板 → 点击 Take Heap Snapshot → 展开
Global Property或Window对象，按大小排序，找体积异常大的属性 - 在 Console 中运行
Object.keys(window).filter(k => window[k] && typeof window[k] === 'object').sort((a, b) => Object.keys(window[b] || {}).length - Object.keys(window[a] || {}).length)，粗筛大对象键名 - 启用 Strict Mode 后，控制台报错
ReferenceError: xxx is not defined往往就暴露了潜在的隐式全局变量
真正有效的解决办法
不是“发现再删”，而是从编码习惯和工程约束入手：
立即学习“Java免费学习笔记（深入）”；
- 所有脚本顶部加
"use strict"，让漏声明变量直接报错，杜绝隐式全局 - 用 ESLint 开启
no-implicit-globals和no-unused-vars规则，CI 阶段拦截问题代码 - 全局命名空间集中管理：如必须暴露，统一挂载到
window.APP = {...}，并定期清理APP.tempCache = null - 动态创建的全局引用（如第三方 SDK 注入），在退出场景（如单页应用路由离开）中显式解绑：
delete window.unneededPlugin或window.unneededPlugin = null
验证是否已修复
改完别急着上线，做两步确认：
- 重复触发疑似泄漏操作（如多次进入/退出某页面），对比前后堆快照中
Global Property下相同 key 的实例数和 retained size 是否稳定不增 - 在 Performance 面板 录制长周期操作，观察内存曲线是否平缓，无阶梯式上升
