esmodule 的静态编译从源头锁定作用域结构，模块顶层自动隔离、严格模式默认启用、import/export 为编译期链接、闭包环境在定义时固化、禁止 eval/with 保障静态可预测性。
ESModule 的静态编译直接决定了作用域的边界和行为，不是“影响”作用域，而是从源头上锁定了作用域的结构。
模块作用域在编译时就完全隔离
每个 .js 文件只要被当作 ES 模块（比如通过 <script type="module"></script> 或 Node.js 中的 .mjs / "type": "module"），它的顶层作用域就自动成为独立模块作用域。这个作用域不是运行时创建的，而是在词法分析阶段就被引擎标记出来——变量、函数、类一旦声明，就只属于该模块，不会泄漏到全局，也不被其他模块直接访问。
- 即使没写任何
export，模块内所有顶层声明（let/const/function）也天然私有 -
this在模块顶层始终是undefined，因为模块默认启用严格模式，且不绑定全局对象 - 不同模块里同名的
let x = 1互不影响，各自拥有独立的词法环境
import/export 不是运行时操作，而是编译期链接声明
import 和 export 语句必须出现在模块顶层，不能放在 if、函数或循环里。这不是语法限制，而是为了保证引擎能在不执行代码的前提下，静态构建出完整的依赖图和绑定关系。
- 导入的变量不是拷贝值，而是建立实时绑定（live binding）：如果原模块导出的是
let count = 0，另一个模块import { count }后修改它，原模块里也能看到变化 - 导出时用
export { foo as bar }这类别名，也是编译期确定的映射，运行时无法动态改名 - 无法用字符串拼接路径做
import，比如import('./' + name + '.js')是非法的——这会破坏静态可分析性
作用域链与函数定义位置强绑定，和执行时机无关
ESM 中函数内部形成的闭包，其 [[Environment]] 引用在函数被定义那一刻就固定了父级词法环境。这个环境来自模块本身的静态嵌套结构，而不是调用时的执行栈。
- 比如模块 A 导出一个函数，模块 B 导入并调用它，该函数内部仍能访问模块 A 的顶层
const api = 'https://...'，因为它的词法父级就是模块 A 的作用域 - 哪怕模块 A 已经执行完毕，甚至被 GC 标记，只要闭包还活着，这条编译期建立的作用域链就一直有效
- 这种静态性让 IDE 补全、ESLint 检查、Tree Shaking 等工具能在编辑或打包阶段准确工作
没有动态作用域干扰，杜绝 eval 和 with
ESM 默认启用严格模式，且明确禁止 eval() 和 with 语句。这两者会在运行时临时修改作用域链，破坏静态可预测性。
-
eval('let x = 1')会把x注入当前作用域，但模块作用域不允许这种运行时注入 -
with(obj)会把对象属性提升为局部变量，导致变量查找路径不可静态推断 - 禁用它们，是为了守住“源码怎么写，作用域就怎么建”这一核心原则
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
