从IIFE到ES Modules，JavaScript模块化历经全局污染、依赖混乱的早期困境，先后诞生命名空间、CommonJS、AMD等方案，最终通过ES6原生支持实现统一，带来静态分析、Tree-shaking和浏览器原生支持，奠定现代前端工程化基础。
JavaScript的模块化发展，本质上是开发者对抗代码混乱、追求可维护性的历史。它从没有标准开始，一步步演进到今天的原生支持。
早期的挣扎：全局污染与依赖混乱
在早期，JS代码直接写在<script>标签里，所有变量都挂在window对象上。随着项目变大，变量名冲突、依赖加载顺序等问题让开发苦不堪言。为了解决作用域污染，开发者们想出了各种办法：
-
命名空间模式：用一个全局对象（比如
MyApp.utils）来包裹相关函数和变量，减少全局污染，但内部成员对外完全暴露，不安全。 - IIFE（立即执行函数）：利用函数作用域隔离变量，通过闭包控制私有和公有成员。这是CommonJS和ES Modules思想的雏形，能有效避免全局污染，也是当时最主流的解决方案。
分叉的道路：服务端与浏览器的不同选择
2009年Node.js的出现，催生了CommonJS规范。它使用require()同步加载模块，module.exports导出接口。这种方式简单直观，在服务器读取本地文件时非常高效，迅速成为Node生态的标准。
然而，浏览器从网络加载资源，同步加载会阻塞页面，体验极差。于是针对浏览器的异步方案应运而生：
立即学习“Java免费学习笔记（深入）”；
-
AMD (Asynchronous Module Definition)：以RequireJS为代表，使用
define()定义模块，require()异步加载。它解决了浏览器的阻塞问题，但写法相对复杂，回调嵌套容易形成“回调地狱”。 - CMD：以SeaJS为代表，理念与AMD类似，但在模块执行时机上有所不同，国内曾有一定应用。
ES Modules：统一标准的诞生与变革
2015年，ES6正式引入了语言层面的原生模块系统——ES Modules (ESM)。它使用import和export语法，带来了根本性的变革：
- 静态分析：ESM的导入导出是静态的，必须在顶层且不能动态修改。这使得工具能在编译时就分析出完整的依赖关系，为Tree-shaking（摇树优化）提供了可能，能自动剔除未使用的代码，显著减小打包体积。
- 官方标准：结束了CommonJS、AMD等规范并存的混乱局面，提供了统一的语言标准，现在已成为现代前端开发的事实标准。
-
动态导入：虽然ESM本身是静态的，但它也支持
import()函数进行动态导入，实现按需加载，兼顾了性能和灵活性。 -
浏览器原生支持：现代浏览器可以直接识别
<script type="module">，无需任何预处理即可运行模块化代码，简化了开发流程。
基本上就这些。从IIFE的智慧到ESM的统一，模块化的发展让JavaScript得以构建起如今庞大的生态系统。
