JavaScript模块系统不改变引擎GC机制，但模块加载方式、作用域和导出引用显著影响对象生命周期：ES模块单例绑定延长变量存活时间；循环依赖与闭包隐式维持强引用；动态import提供可控回收机会；打包工具可能加剧隐式引用问题。
JavaScript模块系统本身不直接改变JS引擎的内存回收机制，但模块的加载方式、作用域管理、导出引用模式会显著影响对象的生命周期和垃圾回收时机。
模块作用域延长变量存活时间
ES模块（import/export）具有静态词法作用域和单例绑定特性。一个被其他模块 import 的模块实例会持续保留在内存中，直到整个模块图（module graph）被卸载（目前主流引擎尚不支持运行时模块卸载）。这意味着：
- 模块顶层声明的函数、对象、类等，在首次导入后不会因作用域退出而被回收
- 即使某个模块只被一个组件临时使用，只要其导出值被其他活跃模块持有引用，它就无法被回收
- 常见陷阱：在模块顶层创建大型缓存对象或绑定 DOM 元素监听器，且未提供清理机制，会导致内存长期驻留
循环依赖与闭包引用链阻碍回收
当模块 A 导入 B，B 又导入 A 时，引擎会通过“已执行但未完全初始化”的中间状态解决循环依赖。这种机制隐式维持了模块环境记录（Module Environment Record）之间的相互引用：
- 每个模块环境都持有一个对其他模块导出对象的强引用
- 若模块导出的是闭包（如返回内部函数并捕获外部变量），可能意外延长外围作用域中大对象的生命周期
- 例如：
export const createProcessor = () => { const bigData = new Array(1e6); return () => bigData.length; };—— 每次调用该函数都会产生一个闭包，若被长期持有（如挂到全局或事件监听器中），bigData就无法释放
动态 import() 带来更可控的回收机会
与静态 import 不同，import() 返回 Promise，加载的模块按需进入模块图。这为内存管理提供了主动干预点：
- 可配合
WeakMap或FinalizationRegistry追踪动态模块的使用状态 - 在业务逻辑结束时，显式将模块导出对象置为
null，断开引用链（尤其当导出对象被赋值给长生命周期变量时） - 注意：当前 V8 和 SpiderMonkey 均未实现模块级卸载（
import.meta.destroy()等提案尚未落地），因此“卸载模块”实际只能靠切断所有外部引用，等待下次 GC
打包工具介入加剧隐式引用问题
Webpack、Vite 等工具将模块打包为闭包函数，模块变量被包裹在 IIFE 中。此时：
- 打包后的模块作用域更难被引擎识别为“可回收”，尤其当存在
eval、with或调试语句时 - Tree-shaking 仅消除未引用的导出，但无法消除已导入却未使用的模块——这些模块仍会执行并占用内存
- 建议：避免在模块顶层执行副作用操作（如初始化大型数据结构、注册全局事件），改用按需初始化函数
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
