ES模块动态加载时作用域隔离靠明确封装机制和加载器约束：每个模块有独立词法作用域，顶层绑定默认私有，仅通过export/import显式通信，import()不破坏该隔离性。
动态模块加载时，作用域隔离不靠“自动魔法”，而靠明确的封装机制和加载器的设计约束。浏览器原生的 import() 是异步的，但每个 ES 模块天然拥有自己的词法作用域——变量、函数、类默认私有，除非显式 export。这是最根本的保障。
ES Modules 的天然隔离机制
每个 .js 文件作为 ES 模块被加载时，都会被置于独立的模块作用域中。这个作用域由 JavaScript 引擎在解析阶段自动创建，与全局作用域、其他模块作用域完全分离。
- 模块内用
const/let/function声明的顶层绑定，不会泄漏到全局或其它模块 - 即使两个模块都定义了
const api = "v1"，它们互不影响，各自保有自己的api - 跨模块通信必须通过
export和import显式声明，没有隐式共享
动态 import() 不破坏隔离性
import("./module.js") 返回 Promise，加载并执行目标模块后才 resolve。它不会把模块内容注入当前作用域，也不会改变当前模块的变量可见性。
- 导入的模块仍运行在它自己的模块作用域中
- 你拿到的只是它
export出来的对象引用，不是它的内部变量副本 - 多次
import()同一个路径，引擎会复用已缓存的模块实例，但每次调用仍遵守同一套作用域规则
自定义加载器（如 AMD/RequireJS）如何模拟隔离
在不支持 ES Modules 的老环境里，模块加载器通过 IIFE + 依赖注入来模拟作用域隔离：
立即学习“Java免费学习笔记（深入）”；
- 每个模块被包裹在立即执行函数中：
(function(define) { define(function(require, exports) { ... }); }) -
require和exports是传入的参数，不是全局变量，避免污染 - 模块工厂函数的执行上下文是闭包，其内部变量对外不可见
- 加载器维护模块注册表，按依赖图拓扑排序执行，确保先加载依赖再执行当前模块
需警惕的“伪隔离”陷阱
隔离不是绝对的，错误实践仍会导致泄漏：
- 在模块顶层直接赋值给
window.xxx或this.xxx，等于主动打破隔离 - 导出一个可变对象（如
export const config = { theme: 'dark' }），其他模块修改它会影响所有引用者——这不是作用域问题，而是引用共享问题 - 使用
eval()、new Function()或内联<script>标签动态执行代码，会绕过模块系统，进入全局作用域
本质上，动态加载只是改变了模块何时进入执行队列，而不是如何定义作用域。只要坚持模块化规范，用好 export/import 或加载器约定，不同模块之间的作用域边界就始终清晰可控。
