为什么模块化在Javascript中如此重要及其实现方式？

模块化解决变量污染、代码复用难、依赖顺序失控及tree-shaking失效问题；ES6 import/export为标准方案，语法静态可分析；CommonJS仍广泛存在，混用时需注意默认导出与module.exports差异。

模块化解决的是什么问题

不使用模块化时，var 声明的变量默认挂载到全局作用域，多个脚本间容易发生变量名冲突；函数和对象反复复制粘贴导致维护困难；无法控制依赖加载顺序，ReferenceError 频发；构建工具也无法做静态分析来剔除未使用的代码（tree-shaking 失效）。

ES6 import/export 是当前标准方案

它由浏览器和 Node.js 原生支持（Node 从 v12.20+ 默认启用 ES 模块），语法简洁、静态可分析、支持命名导出与默认导出混合使用。

• export 必须在顶层作用域，不能在条件语句或函数内
• import 路径必须是字符串字面量，不支持拼接（如 import('./' + name + '.js') 是动态导入，语法不同）
• 默认导出（export default）一个模块只能有一个，导入时名字可任意；命名导出（export const x = 1）可多个，导入时名字必须匹配或用 as 重命名

export const PI = 3.14;
export function add(a, b) { return a + b; }
export default class Calculator { }

import Calculator, { PI, add } from './math.js';

CommonJS 在 Node.js 早期生态中仍广泛存在

虽然 Node 已支持 ES 模块，但大量 npm 包（尤其老版本）仍以 module.exports 和 require() 输出。混用时需注意：require() 无法直接读取 export default 的值（会得到 { default: ... }），而 import 加载 CommonJS 模块时，其 module.exports 对象会被当作默认导出。

• Node 中启用 ES 模块需在 package.json 中设置 "type": "module"，否则 .js 文件按 CommonJS 解析
• 动态 require() 在 ES 模块中不可用，应改用 import()（返回 Promise）
• Webpack/Vite 等打包器能自动处理二者互调，但裸运行环境（如 Node CLI）会报错

模块路径解析和循环依赖的真实表现

ES 模块在编译阶段就解析依赖图，路径必须明确——相对路径（./utils）、绝对路径（/src/index）或包名（lodash）；而 CommonJS 的 require('lodash') 会在运行时沿 node_modules 逐层查找。

循环依赖在两种系统中行为不同：CommonJS 返回已执行部分的 exports 对象（可能为不完整状态）；ES 模块则提前创建绑定（live binding），即使模块尚未执行完，导入的值也会随原始值变化而更新。

真正棘手的不是语法怎么写，而是当一个模块同时被 ESM 和 CommonJS 方式引用，且内部有副作用（如立即执行的初始化逻辑），结果可能因加载时机差异而不可预测。