JavaScript模块化历经从无到有，解决命名冲突与依赖管理难题。早期通过script标签引入文件，导致全局污染；CommonJS在Node.js中实现服务端模块化，采用同步加载；AMD（如RequireJS）支持浏览器异步加载；UMD兼容CommonJS与AMD；ES6原生支持import/export，成为标准；现代发展引入动态import()与ESM在Node.js中的支持，结合构建工具优化性能。当前推荐使用ES模块为开发标准，推动前端工程化成熟。
JavaScript的模块化发展经历了从无到有、从混乱到规范的过程，主要为了解决代码组织混乱、命名冲突和依赖管理困难等问题。随着前端项目规模扩大，模块化成为必须。
早期：无模块化阶段
在早期浏览器环境中，JavaScript没有原生模块机制，所有脚本共享全局作用域。
- 开发者通过script标签引入多个js文件，变量和函数容易污染全局命名空间
- 依赖关系靠手动维护，加载顺序至关重要
- 典型问题如“命名冲突”和“难以维护”频繁出现
CommonJS：服务端模块化的兴起
Node.js采用CommonJS规范，实现了服务端的模块化。
- 使用require()同步加载模块，module.exports导出接口
- 每个文件是一个独立模块，作用域隔离
- 由于同步加载，不适合浏览器环境（网络延迟高）
- 但催生了npm生态，极大推动了包管理发展
AMD与RequireJS：浏览器异步模块尝试
为解决浏览器中异步加载问题，AMD（Asynchronous Module Definition）出现。
立即学习“Java免费学习笔记（深入）”；
- 代表实现是RequireJS，支持按需异步加载模块
- 使用define()定义模块，支持依赖前置声明
- 语法相对复杂，学习成本较高
- 在Webpack等工具普及前被广泛用于大型前端项目
UMD：兼容多环境的折中方案
UMD（Universal Module Definition）试图统一CommonJS和AMD。
- 生成的模块可在Node.js、AMD加载器或全局变量中运行
- 本质是兼容性包装，代码冗余较多
- 常见于需要发布通用库的场景
ES6模块：语言层面的原生支持
ES2015（ES6）正式引入原生模块系统，成为标准。
- 使用import和export语法，静态分析支持 tree-shaking
- 模块默认严格模式，文件级作用域
- 浏览器逐步支持，通过type="module"启用
- 构建工具如Webpack、Vite优先支持ESM
现代发展：动态导入与混合使用
ES模块持续演进，支持更灵活的使用方式。
- 动态import()返回Promise，实现按需加载
- Node.js全面支持ESM（.mjs文件或package.json中设置"type": "module"）
- 存在ESM与CommonJS共存的过渡问题，如互操作性限制
- 打包工具在生产中仍广泛使用，优化加载性能
基本上就这些。JavaScript模块化从全局污染走到标准化，反映了前端工程化的成熟过程。现在推荐使用ES模块作为开发标准，结合现代构建工具提升效率。虽然历史方案仍在维护项目中可见，新项目应优先选择原生模块体系。
