本文讲解如何通过将模块逻辑封装为函数而非顶层变量声明，规避 JavaScript 模块初始化时的“访问未初始化变量”错误（ReferenceError），从而构建 main → a → b → main 的单向数据流，同时支持环境参数注入与终端运行。
本文讲解如何通过将模块逻辑封装为函数而非顶层变量声明，规避 javascript 模块初始化时的“访问未初始化变量”错误（referenceerror），从而构建 `main → a → b → main` 的单向数据流，同时支持环境参数注入与终端运行。
在 ES 模块系统中，顶层变量声明的执行顺序严格依赖导入图（import graph）的拓扑排序。当 main.js 导入 b.js，b.js 导入 a.js，而 a.js 又导入 main.js 时，即便实际数据流不构成循环依赖（如 fromMain 并不依赖 fromB 的值），模块加载器仍会按静态导入关系构建初始化链。此时若各模块均在顶层直接读取/计算变量（如 const fromA = fromMain + 456），就会触发 ReferenceError: can't access lexical declaration 'X' before initialization —— 因为 main.js 的导出绑定尚未完成初始化，就被 a.js 提前访问。
根本解法是：将所有非导出声明的计算逻辑延迟到函数调用时执行，而非模块加载时求值。这样，模块仅导出函数（而非立即求值的值），彻底解除初始化时序耦合。
✅ 正确实践：函数封装 + 惰性求值
以下为适配 Deno（或通用 ESM 环境）的重构方案：
main.js：
// ✅ 导出环境变量（可动态获取）
export const fromEnvironment = Deno.args[0] ?? 'default';
// ✅ 延迟执行：仅在最后调用 fromB()，此时所有模块已就绪
import { fromB } from './b.js';
console.log(fromB()); // 输出如 "123456789"a.js：
import { fromEnvironment } from './main.js';
// ✅ 不再导出变量，而是导出纯函数
export function fromA() {
return fromEnvironment + 456;
}b.js：
import { fromA } from './a.js';
// ✅ 同样使用函数封装，确保调用时才访问 fromA()
export function fromB() {
return fromA() + 789;
}运行命令（Deno 示例）：
deno run main.js 123 # 输出：123456789
⚠️ 关键注意事项
- 禁止顶层副作用计算：任何依赖其他模块导出值的计算（尤其是字符串拼接、数值运算等）必须包裹在函数内，不可置于模块顶层作用域。
- 导出命名一致性：确保 export { X } 与 import { X } 的名称完全匹配，ESM 不支持默认导出自动重命名。
- 环境兼容性：本方案适用于 Deno、Node.js（启用 "type": "module"）、现代浏览器等标准 ESM 环境；若需兼容 CommonJS，需额外转译。
- 调试友好性：函数式结构更易单元测试——可单独 import { fromA } from './a.js'; console.assert(fromA() === '123456');。
✅ 总结
解决此类“伪循环依赖”问题的核心思想是：分离模块的“声明阶段”与“执行阶段”。模块只负责声明（导出函数），不负责执行（计算值）；真正的数据流控制权交还给入口文件（main.js）——它按需调用函数，形成清晰、可控、无时序风险的执行链。这种模式不仅规避了 ReferenceError，还提升了代码可测试性、可维护性与环境适应性。
