全局变量阻碍垃圾回收，因其使对象始终可达而无法被标记清除；应通过堆快照定位、严格模式预防、模块封装及WeakMap等弱引用机制优化。
全局变量会持续占据内存，直到页面卸载，容易造成内存泄漏，尤其当它们意外引用了本该被回收的DOM节点或大型对象时。
全局变量为何阻碍垃圾回收
JavaScript的垃圾回收器（如V8的Orinoco）采用标记-清除机制：从根对象（如全局对象window或globalThis）出发，遍历所有可到达的对象，未被标记的才被回收。一旦某个对象被全局变量直接或间接持有，它就始终“可达”，无法被回收。
- 例如：window.userData = { profile: largeImageBlob, settings: {} } —— 即使用户已离开相关页面，largeImageBlob仍驻留内存
- 闭包中无意捕获全局引用也会延长生命周期：const timer = setInterval(() => console.log(window.data), 1000)，只要定时器没清除，window.data就无法释放
- 第三方库若将实例挂到window上（如window.myLibInstance = new Lib()），且未提供销毁方法，极易累积内存
识别和清理不必要的全局变量
优先使用浏览器开发者工具定位问题：
- 在Memory面板中录制堆快照（Heap Snapshot），筛选Global Property或按(global property)排序，查看哪些变量体积大、生命周期长
- 用console.memory监控内存变化，在关键操作前后对比usedJSHeapSize
- 检查代码中所有var声明（无let/const块级作用域时易污染全局）、隐式全局（如忘记var直接赋值myVar = {}）及window.xxx = ...写法
替代方案与安全实践
避免依赖全局变量，改用更可控的作用域和生命周期管理：
立即学习“Java免费学习笔记（深入）”；
- 用模块封装：ES6模块天然隔离作用域，导出必要接口，内部变量默认不可见
- 用弱引用解耦：对需缓存但不阻止回收的对象，考虑WeakMap（键为对象，不阻止其被回收）或WeakRef + FinalizationRegistry（适用于高级清理场景）
- 显式生命周期控制：为挂载到全局的对象设计destroy()方法，并在路由离开、组件卸载等时机调用；配合beforeunload事件做兜底清理
- 启用严格模式：'use strict'可防止意外创建隐式全局变量
构建时的预防措施
从工程层面降低风险：
- 配置ESLint规则，如no-implicit-globals、no-unused-vars、no-global-assign，在开发阶段拦截问题
- 使用TypeScript并开启noImplicitAny和strict模式，强制声明变量作用域
- CI流程中加入内存基线检测，例如用Puppeteer运行典型用户流并比对堆增长幅度
