JS模块化实现方式解析

由于JavaScript最初的设计定位，语言本身未内置模块系统，但随着应用规模不断扩大，模块化逐渐成为必须解决的关键问题。

1、 模块化需解决哪些问题

2、 深入分析需明确目标，模块化旨在解决复杂系统的结构与管理问题。

3、 通过模块化设计，清晰划分职责，提升代码可维护性。

4、 举个简单例子，现有如下代码：

5、 在实际应用中，doSomething 可能涉及大量操作，add 函数也可能更加复杂且需要多次复用。为了提高代码的可维护性和复用性，我们倾向于将 add 函数单独提取出来，存放到独立的文件中进行管理。

6、 这样做的目的十分明确，旨在更好地组织项目代码结构。观察两个文件中的 require 和 module.exports，从当前角度看，它们源自 CommonJS 规范中的关键词，分别用于模块的导入与导出，而这正是模块化发展过程中需要解决的核心问题之一。通过这种方式，既能实现 add 模块的复用，又能避免引入该模块时对全局作用域造成污染，从而提升代码的可维护性与独立性，为后续的开发和扩展打下良好基础。

7、 引入模块的运行机制解析

8、 在上述示例中，代码已拆分至两个模块文件，如何通过 require 实现模块间正常调用，同时避免全局污染，确保程序正确运行。

9、 暂不讨论模块文件的加载过程，假设 require 已能获取模块中的代码字符串，那么其实现方式可以如下所示。

10、 几点关键要素

11、 通过 new Function 执行代码字符串，多数人可能不太熟悉这种方法，因为在常规开发中定义函数无需如此。实际上，Function 构造器允许直接动态创建函数，其语法结构清晰明确，能够在运行时生成并执行函数逻辑，具备较强的灵活性与动态性。

12、 每个参数均为字符串形式，最后一个参数为函数体代码。该方法支持将字符串作为代码执行，功能类似eval，但更进一步的是，允许通过参数向字符串代码中传入变量值，实现动态执行与外部数据的交互，提升了灵活性和安全性，适用于需要运行时构建并执行代码的场景。

13、 代码加载方法

14、 在解决代码运行问题后，还需处理模块文件的加载，目标是将模块代码以字符串形式读取并载入，如前述示例所示。

15、 在 Node 容器中，所有模块文件均存储于本地，只需从本地磁盘读取文件内容，获取代码字符串后按既定流程加载执行即可。实践表明，对于非内置、非核心及非 C++ 扩展模块，Node 的加载机制基本遵循这一模式，尽管实际实现中并未直接使用 new Function，但其原理类似，本质仍是动态执行字符串形式的代码。

16、 在 RN 或 Weex 容器中，加载远程的 bundle.js 文件时，可借助原生能力发起网络请求获取 JS 文件内容，再将其读取为字符串形式动态执行。这种机制本质上是将远程脚本拉取到本地运行。类似地，Node 环境理论上也可通过网络读取远程模块并加载，尽管实际开发中较少采用这种方式。

17、 在浏览器中，JavaScript 模块需从远程加载，但由于浏览器限制，无法通过 AJAX 将远程 JS 文件以文件流形式直接读取为字符串代码。由于这一前提无法满足，原本的执行策略难以实现，因此必须寻找其他可行的方法来完成模块的加载与运行。

18、 正是因为CommonJS存在局限，才催生了AMD、CMD等更适合浏览器环境的模块规范。

19、 浏览器中如何实现？通过 JavaScript 动态加载远程 JS 模块文件时，需创建并插入一个 script 标签，将其添加到页面 DOM 中，从而实现脚本的动态引入与执行。

20、 当为 script 标签设置 src 属性后，一旦脚本下载完成便会立刻执行，无法再进行闭包封装。因此，模块在设计之初就必须考虑隔离性与依赖管理，这就催生了 AMD 和 CMD 等模块规范。通过 define 函数定义模块，确保代码的独立运行和按需加载，像开头的 add.js 就需要按照规范重新组织结构。

21、 现在可以通过模块名从 context.modules 中加载对应模块，实现类似 require 的功能，你是否也萌生了亲手打造一个requirejs的想法？整个过程直观而有趣，让人跃跃欲试。

22、 AMD的具体实现确实更为复杂，涉及模块加载顺序、依赖管理等诸多细节。但只要掌握了其核心原理，深入理解require.js的源代码自然也就水到渠成，不再困难。

23、 Webpack 模块化机制解析

24、 Webpack 支持配置异步模块，在浏览器中通过动态插入 script 标签来加载远程模块。大多数情况下，模块的加载方式与 Node 中从本地磁盘同步读取类似，但在异步场景下则采用动态加载机制，实现按需加载和代码分割，提升性能与用户体验。

25、 别忘了，Webpack 不仅具备模块化功能，更是一个优化开发流程的工具。其模块化处理主要在开发阶段完成。借助 Webpack 搭建的开发环境，尽管代码以独立模块形式编写，但在实际运行时，所有模块会被打包合并成一个完整的文件，提升加载效率与执行性能。

26、 Webpack 是一种非运行时的模块化方案，主要基于 CommonJS 规范。只有在配置异步模块时，其加载过程才发生在运行时，此时采用的是 AMD 规范。

27、 模块化设计准则

28、 在解决问题的过程中，通用方案常会演变为规范。前文屡次提及 CommonJS、AMD 和 CMD，因此有必要专门探讨这些规范的由来与意义。

29、 JavaScript模块化规范的兴起源于将其拓展至后端领域的设想。为了让JavaScript具备如Python、Ruby和Java那样开发大型应用的能力，模块化成为关键基础。CommonJS规范应运而生，为JavaScript描绘了一个广阔前景：使其不仅能在浏览器中运行，还能在服务器端、桌面端乃至更多环境中无缝执行，真正实现随处运行的理想目标。

30、 运行在服务器的JavaScript程序

31、 命令行工具

32、 桌面程序

33、 融合应用

34、 CommonJS 模块定义简洁，主要包括模块引用、定义与标识三个部分。

35、 通过 require 方法导入所需模块

36、 模块通过 exports 导出其对象内容

37、 模块标识指传给 require 方法的参数，可为小驼峰命名字符串、相对路径或绝对路径。

38、 CommonJS 规范在 Node.js 环境中广泛应用并推动了模块化发展，但由于浏览器依赖网络加载资源，采用同步方式加载模块显得不够现实。经过一段时间的讨论与权衡，前端领域最终倾向于采用 AMD 规范。AMD 全称为异步模块定义（Asynchronous Module Definition），它支持异步加载模块，更适应浏览器环境的特性，提升了页面性能与用户体验。

39、 AMD是一种模块化开发规范，用于解决JavaScript在浏览器中异步加载模块的问题，提升代码可维护性与加载效率。

40、 此外，国内玉伯还提出了 CMD 规范。与 AMD 相比，主要区别在于：AMD 要求在模块定义时声明所有依赖，而 CMD 支持在运行过程中动态加载模块，语法风格更贴近 CommonJS，灵活性更高。

41、 两种规范均需从远程网络加载模块，区别在于前者为预加载，后者为按需延迟加载。