ESM模块执行分实例化与求值两阶段：实例化仅建立导出绑定（非值）并完成依赖映射，不执行代码；求值按拓扑序执行顶层语句，赋予绑定真实值并支持实时绑定。
模块实例化与求值分离，是 ES Module（ESM）执行机制的核心设计，它让 JavaScript 的模块系统具备确定性、可预测性和静态分析能力。简单说：实例化阶段只建立变量绑定关系，不执行任何代码；求值阶段才真正运行顶层语句、赋值、调用函数等操作。
实例化阶段：只链接，不执行
这个阶段发生在模块被加载并解析为 ModuleRecord 之后，但在任何代码运行之前。它的核心任务是：
- 为每个模块创建一个“实例”，即一块内存空间，用于存放所有 export 的绑定（注意：不是值，而是对变量的引用）
- 将所有 import 语句映射到对应模块的 export 绑定上，形成静态的、单向的“绑定连接”
- 这个过程是深度优先、自顶向下的，从入口模块开始，递归处理整个依赖图，确保所有模块都完成实例化后才进入下一步
- 此时即使某个 export 是一个函数调用或计算表达式（比如
export const x = Math.random()），也不会求值——x 只是一个未初始化的绑定，访问会报ReferenceError
求值阶段：按顺序执行顶层代码
只有当整个依赖图中所有模块都完成实例化后，引擎才开始求值。它严格遵循拓扑排序顺序（即依赖项先于被依赖项），保证 import 总能读到已求值的 export 值：
- 从入口模块开始，逐行执行其顶层语句（包括声明、赋值、函数调用、副作用逻辑等）
- 一旦某个模块的求值完成，它的所有 export 绑定就拥有了真实值；其他模块通过 import 引用的，就是这些实时的、动态的值
- 由于绑定是动态的（live binding），如果模块 A 导出一个 let 变量
export let count = 0，模块 B 导入并修改它（import { count } from './a.js'; count++），模块 A 内部读取 count 也会看到更新后的值 - 循环依赖在这种机制下也能安全处理：实例化阶段已建立双向绑定，求值时各自执行到一半，再通过绑定访问对方已求值的部分
为什么这样设计？关键好处
这种分离不是为了增加复杂度，而是解决实际工程问题：
- 避免执行顺序歧义：如果 import 同时触发加载、实例化和求值，依赖链中某模块提前执行，可能读到未定义的值
- 支持静态分析与工具链：打包器（如 Vite、Rollup）可在不运行代码的前提下，准确识别 import/export 关系，实现 tree-shaking
- 保障绑定语义一致性：export 不是快照值，而是活引用，使模块间状态同步成为可能，也符合 JavaScript 的词法环境直觉
-
与 CommonJS 的根本区别：CommonJS 的
require()是运行时同步执行 + 立即返回值（快照），而 ESM 的 import 是编译时声明 + 运行时动态绑定
不复杂但容易忽略：实例化 ≠ 初始化，求值 ≠ 执行任意时机——它是两个明确、有序、不可跳过的阶段。
