模块实例化阶段let/const变量处于TDZ：绑定已创建但未初始化，提前访问触发ReferenceError；函数导出可绕过该问题，而var因默认初始化为undefined无TDZ风险。
模块实例化阶段对 let/const 变量的“未初始化”状态处理，核心在于 ES 模块的静态绑定机制与暂时性死区（TDZ）的叠加效应——它不是运行时延迟赋值的问题，而是模块加载过程中词法绑定已存在、但初始化尚未发生的确定性状态。
模块实例化分两步：绑定声明 + 执行顶层代码
ES 模块加载流程中，“实例化”阶段会预先创建所有 export 绑定（即变量名与内存位置的映射），但此时并不执行赋值。只有进入“求值”（evaluation）阶段，才按依赖顺序逐个执行模块顶层语句。对于 let/const：
- 声明会被提升到模块作用域顶部（类似
var的绑定提升），但不初始化； - 该变量从声明点开始，到实际赋值语句执行前，始终处于 TDZ 状态；
- 若另一模块在本模块完成求值前就尝试读取这个导出绑定（比如循环导入中 a.js 读 main.js 的
fromMain），就会触发ReferenceError。
为什么 import 不等于“等它执行完”
ES 模块的 import 是静态声明，不阻塞执行流。当 b.js 导入 a.js，而 a.js 又导入 main.js 时，引擎会尝试并行解析整个图谱。但求值必须按拓扑序进行——如果环存在，就必然有某个模块的导出变量被提前访问，而它对应的 let/const 还卡在 TDZ 里。
例如：main.js 顶层写 const fromMain = Deno.args[0];，a.js 在顶层就写 import { fromMain } from './main.js'; console.log(fromMain);。即使逻辑上 fromMain “应该已有值”，模块系统仍会报错，因为 main.js 的求值尚未开始或未完成。
函数导出是绕过 TDZ 的有效手段
把变量改为函数返回值，本质是把“访问时机”从模块实例化/求值阶段，推迟到函数调用时刻——此时所有模块早已加载完毕，所有 let/const 都已完成初始化。
- 函数体内的
fromEnvironment引用发生在运行时，而非模块绑定阶段； - 模块只导出一个已初始化的函数对象（函数本身是
const绑定，无 TDZ 风险）； - 调用链
fromB() → fromA() → fromEnvironment全部落在求值完成后，彻底避开初始化时序冲突。
对比 var 就不会出这个问题？
var 声明虽有变量提升，但它的“初始化”在声明时就默认为 undefined，不存在 TDZ。所以即使循环导入中提前读取，最多得到 undefined，不会报错。但这恰恰掩盖了依赖问题，且 var 的函数作用域和可重复声明等特性，在模块化场景下反而更易引发隐蔽错误。现代模块设计明确要求用 let/const，因此必须正视 TDZ 的约束，而不是回避它。
