ES Modules通过实时绑定机制解决循环引用,解析阶段建立导出绑定关系,实例化阶段创建绑定槽,执行阶段赋值并动态反映最新值。

ES Modules 用实时绑定(live binding)机制解决循环引用,不是靠“避免”,而是让模块间能安全地互相访问尚未完全初始化的导出值。
循环引用在 ES Module 中如何实际运行
当两个模块 A 和 B 相互 import,ESM 的处理分三步:解析(parse)、实例化(instantiate)、执行(execute)。关键点在于——
- 解析阶段就建立所有模块的导出绑定关系,但此时变量还没赋值
- 实例化阶段为每个导出创建“绑定槽”(binding slot),类似一个指向变量内存位置的指针
- 执行阶段才真正运行代码、给变量赋值;其他模块通过绑定槽读取,读到的是最新值(或 undefined,如果还没赋值)
为什么 console.log(b) 在 a.js 里输出 'b',而 console.log(a) 在 b.js 里输出 undefined
这反映的是执行顺序和变量初始化时机的差异:
使用约定式提交(Conventional Commits)生成标准化的 Git 提交信息。适用于以下场景: (1) 暂存更改时需要提交信息; (2) 审查 diff 时希望获得结构化摘要; (3) 编写 PR 描述或变更日志(changelog)条目; (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff,并生成按类型(type)划分范围的提交信息。
- a.js 先被加载,执行到 import { b } from './b.js' 时,b.js 进入解析和实例化,但还没执行;此时 b.js 的 export let b = 'b' 还未运行,所以 b 的绑定槽里是 undefined
- b.js 执行时,先运行 import { a } from './a.js',这时 a.js 已完成实例化,export let a = 'a' 的绑定槽已存在,但 a 的赋值语句还没执行(还在 a.js 后面),所以读出来是 undefined
- 等 a.js 继续执行到 a = 'a',b.js 里对 a 的读取会立刻反映出这个新值(因为是绑定,不是拷贝)
CommonJS 对比:值拷贝导致“冻结快照”
CommonJS 的 require 是运行时同步执行,模块一被 require 就立即执行全部代码并缓存 module.exports 的值:
- 如果 a.js require('./b.js'),而 b.js 又 require('./a.js'),那么 b.js 会拿到 a.js 当前 module.exports 的“快照”,哪怕 a.js 后面还改了 exports,b.js 看不到
- 没有绑定机制,无法响应后续变化,循环中容易拿到不完整或过期的对象
- 更依赖开发者手动控制导出时机(比如导出函数而非原始值),否则容易出错
写法上怎么减少循环引用风险
即使机制可靠,也不建议主动设计强循环依赖。可采取这些实践:
- 把共享状态或工具函数抽到第三个模块中,A 和 B 都 import 它,而不是彼此 import
- 导出函数代替导出原始值,函数体内再访问其他模块,延迟依赖求值
- 在模块顶层避免直接使用另一个模块的未初始化变量;把调用逻辑移到函数体内或事件回调中
- 用动态 import() 拆解强耦合,例如在某个方法里 const { helper } = await import('./helper.js')










