JavaScript 模块系统：ESM 与 CommonJS 全解析
模块化设计的必要性
代码组织的困境
想象一下，你正在写一本很长的书。最开始，你可能觉得把所有章节、笔记和角色简介都放在一个巨大的文档里很方便。但随着故事越来越复杂，这个文档会变得臃肿不堪，难以驾驭。想找一段特定的对话？你得滚动浏览几百页。想修改一个角色的名字？你必须手动搜索并替换每一次出现，还可能漏掉一两个。
早期的 JavaScript 开发就像管理这个巨大的文档。开发者们习惯将所有的代码都放在一个或少数几个文件中。这些文件在浏览器中加载时，会共享同一个“空间”，我们称之为全局作用域（Global Scope）。
全局作用域的陷阱
全局作用域就像一个公共广场的公告板。任何人都可以往上面贴东西，也可以撕掉或覆盖别人的告示。起初，这似乎很高效，信息共享很直接。但当贴告示的人多起来时，问题就出现了。
假设两个不同的团队都在这个广场上工作。一个团队贴了张告示，上面写着：“会议地点：市政厅”。另一个团队不知道，也贴了一张告示，覆盖了前一张，写着：“会议地点：图书馆”。现在，所有看到公告板的人都会去错误的地方开会。这就是命名冲突。
当不同部分的代码意外地使用了相同的变量名或函数名时，就会发生命名冲突，导致一个覆盖另一个，引发难以追踪的错误。
让我们看一个具体的代码示例。假设你的网页需要两个脚本：一个用于显示用户欢迎信息，另一个用于管理购物车中的商品数量。
<!-- welcome.js -->
var name = "Alice";
function displayWelcome() {
console.log("Welcome, " + name);
}
<!-- cart.js -->
var name = "Shopping Cart"; // 命名冲突！
var items = ["Apple", "Banana"];
function getCartItemCount() {
console.log(name + " has " + items.length + " items.");
}
如果你在 HTML 页面中同时加载这两个脚本，后加载的 cart.js 会把 name 变量的值从 "Alice" 改为 "Shopping Cart"。结果，欢迎信息就会出错，显示 “Welcome, Shopping Cart”，这显然不是我们想要的。
除了命名冲突，代码的可维护性也是一个巨大挑战。当所有代码都混杂在一起时，它们之间会形成一张看不见的依赖网。修改一处代码，你很难确定是否会影响到其他不相关的功能。这就像在玩叠叠乐，抽出一块积木，整座塔都可能轰然倒塌。
模块化：代码的整理术
为了解决这些问题，开发者们引入了模块化（Modularity）设计的思想。模块化就是将一个大型程序分解成一个个独立的、可互换的“模块”的过程。每个模块都有自己明确的功能，并且只暴露必要的接口与外部通信，隐藏内部的实现细节。
将复杂的项目分解成逻辑上独立的模块，是有效管理上下文的关键。
这就像整理你的衣柜。你不会把衬衫、袜子和裤子都扔在一个大堆里，而是把它们分别放进不同的抽屉。每个抽屉就是一个模块。当你需要找袜子时，你只需要打开“袜子”抽屉，而不用翻遍整个衣柜。每个抽屉（模块）内部可以很整洁，也可以有点乱，但这不会影响到其他抽屉。
模块化设计带来了几个核心优势：
- 避免命名冲突：每个模块都有自己的私有作用域。模块内的变量和函数默认是私有的，不会污染全局空间。除非你明确地导出（export）它们，否则外部无法访问。
- 提高可维护性：代码按功能划分到不同模块中，结构清晰。当你需要修改某个功能时，你只需要关注相关的模块，大大降低了“牵一发而动全身”的风险。
- 促进代码重用：一个设计良好的模块可以在不同的项目中被重复使用。例如，一个用于处理日期格式化的模块，可以被用在任何需要此功能的项目中，无需重写。
- 明确依赖关系：模块化系统要求你明确声明一个模块需要依赖哪些其他模块。这使得代码的依赖关系一目了然，方便管理和理解。
现在，你应该明白了为什么现代 JavaScript 开发离不开模块化。它不是一个可有可无的选项，而是构建健壮、可维护应用程序的基石。
在早期的 JavaScript 开发中，将所有代码都放在全局作用域中会引发的主要问题是什么？
根据文中的比喻，将大型程序分解成独立的模块，就像整理衣柜时把衬衫、袜子和裤子分别放进不同的_____。
在接下来的章节中，我们将深入了解 JavaScript 中实现模块化的两种主流标准。