ES Modules 是一套分构造→实例化→求值三阶段的严格加载协议，依赖浏览器规范执行；路径格式声明需精确，模块边界靠导出契约而非目录结构；与构建工具共生，为 Tree Shaking 和 HMR 提供静态分析基础。
ES Modules 不是语法糖，而是一套有明确阶段、严格约束、可被工具深度利用的加载协议。要真正看懂它，得跳出“怎么写 import/export”的表层，从浏览器执行流程、模块生命周期和工程约束三个层面一起看。
浏览器里它分三步走：构造 → 实例化 → 求值
这不是理论模型，是所有现代浏览器（Chrome、Firefox、Safari）实际遵循的规范流程：
-
构造阶段：只扫描、不执行。浏览器拿到
type="module"脚本后，静态解析所有import，生成模块记录（Module Record），并发起并行请求下载依赖。此时连变量内存都没分配，更不会运行任何代码。 -
实例化阶段：分配内存 + 建立绑定。为每个模块的导出变量分配存储槽位，并把所有
import指向对应export的内存地址——这就是 live binding 的本质：不是拷贝值，而是共享同一块内存。 -
求值阶段：按拓扑顺序执行顶层语句。从没依赖的模块（叶子）开始，逐级向上执行。只有这时，
export let count = 0才真正把0写进内存；也只有这时，其他模块才能读到它的值。
路径、格式、声明一个都不能少
ESM 对细节极其敏感，错一点就报错，不是 bug，是设计使然：
- HTML 中必须写
<script type="module" src="app.js"></script>，缺了type="module"就当普通脚本处理，import直接 SyntaxError。 - 导入路径必须是字符串字面量：不能拼接变量，不能用
if包裹import，也不能省略扩展名——import { fn } from './utils'❌，import { fn } from './utils.js'✅。 - Node.js 中启用 ESM 要么设
"type": "module"在package.json，要么用.mjs后缀；CommonJS 文件里不能用require()加载 ESM 文件，但可以用import()动态导入。
模块边界不是目录结构，而是导出契约
组件化项目里，清晰的模块边界靠的是人为定义的接口规则，不是文件夹命名：
- 每个文件只导出它真正对外负责的东西：组件类、配置常量、渲染函数。内部工具函数、私有状态、未封装的 DOM 操作一律不暴露。
- 禁止
import * as xxx，尤其在组件调用侧——它模糊依赖、阻碍 Tree Shaking、容易引发命名冲突。应明确写import { Button, BUTTON_SIZES } from './Button.js'。 - 入口文件（如
index.js）只做有限 re-export，不透传深层工具或内部模块；子模块之间不跨层直连，统一走shared/或lib/公共层。
它和构建工具是共生关系，不是独立存在
ESM 本身不优化、不压缩、不拆包，但它为 Vite、Rollup、Webpack 提供了可信赖的静态图谱：
- Vite 把 ESM 当原生前提：开发时直接托管模块，构建时基于静态 import 分析做代码分割；没有 ESM，就没有开箱即用的 HMR 和按需加载。
- Tree Shaking 能生效，前提是 ESM 语法 + 生产模式 + 无副作用声明（
"sideEffects": false）。CommonJS 的require()是动态的，构建工具无法静态判定哪些代码没被用到。 - npm 包是否可用，取决于
package.json里有没有正确声明 ESM 入口："exports"字段优先于"module"，再优先于"main"；Vite 报 “default is not exported”，大概率是包只提供了 CommonJS 格式。
