? 先搞懂啥是 CMD 规范和 CommonJS
很多刚接触前端模块化的同学，一听到 CMD、CommonJS 这些名词就头大，总觉得它们长得像，功能也差不多。其实不然，这俩规范从诞生背景到实际用法，差别都不小。
先说说 CommonJS，它最早是为了解决 JavaScript 在服务器端的模块化问题而生的。你想啊，早期 JavaScript 主要在浏览器里跑，代码量不大，随便写几行就行。但当它跑到服务器端，比如 Node.js 环境，代码量飙升，没有模块化根本玩不转 —— 总不能把所有代码都堆在一个文件里吧？所以 CommonJS 就站出来了，它规定了一套模块定义、依赖加载的规则，让服务器端的 JavaScript 也能像 Java、Python 那样，按模块拆分，方便管理。
再看 CMD 规范，它全名叫 Common Module Definition，翻译过来是通用模块定义。这货是国内开发者提出来的，最开始是 SeaJS 这个库在推广。它的目标更偏向浏览器端，因为浏览器加载脚本是异步的，要是模块加载处理不好，很容易出现代码执行顺序混乱的问题。CMD 就是想在浏览器环境下，搞一套更灵活、更符合前端开发习惯的模块化方案。
简单说，CommonJS 是服务器端模块化的 “老大哥”，CMD 则是浏览器端模块化的 “探索者”。虽然现在 ES6 模块（ESM）已经成了主流，但了解这俩规范，能帮你更好地理解 JavaScript 模块化的发展脉络，遇到老项目也能快速上手。
? 从核心机制看，两者区别真不小
模块定义方式，一眼就能看出差别。CommonJS 里，定义一个模块特别直接，随便一个.js 文件就是一个模块。你想导出模块里的内容，用 module.exports 或者 exports 就行。比如你写了个工具函数文件 utils.js，想导出一个 formatDate 函数，直接写 module.exports = {formatDate}；或者 exports.formatDate = formatDate，都能行。导入的时候更简单，用 require 函数，比如 const { formatDate } = require ('./utils.js')，一句话就搞定。
CMD 就不一样了，它要求用 define 函数来包裹模块代码。这个 define 函数可以接收一个工厂函数，里面能传三个参数：require、exports、module。比如同样是定义工具模块，CMD 里得写成 define (function (require, exports, module) { function formatDate () { ... } exports.formatDate = formatDate })。导入的时候，也是在这个工厂函数里用 require，比如 const utils = require ('./utils.js')。这种方式看起来比 CommonJS 多了一层包裹，但好处是能更清晰地标识这是一个模块。
依赖加载时机，这是两者最核心的区别。CommonJS 是 “加载即执行”，而且是同步加载。啥意思？当你用 require 导入一个模块时，Node.js 会立刻去读取这个模块的文件，执行里面的代码，然后把 module.exports 的结果缓存起来。下次再 require 同一个模块，直接用缓存，不会再执行代码。这种同步加载在服务器端没问题，因为模块文件都在本地硬盘，读取速度快，不会造成太大阻塞。但要是放到浏览器端就麻烦了 —— 浏览器加载脚本得从网络上下载，同步加载会让页面卡住，用户体验直接崩了。
CMD 则是 “按需加载”，也叫 “延迟执行”。它不会在模块加载完成后就立刻执行所有代码，而是等到代码里真正用到某个依赖的时候，才会去加载并执行那个依赖模块。比如你在 CMD 模块里写了一段代码，开头用 const a = require ('./a.js')，但后面几百行才用到 a 的方法，那 a 模块的加载和执行就会推迟到第一次用到它的时候。这种机制特别适合浏览器环境，能减少不必要的资源加载，提升页面响应速度。
适用场景也跟着机制走。CommonJS 天生适合服务器端，Node.js 从一开始就采用了它，现在绝大多数 Node.js 项目都是用 CommonJS 规范来组织代码的。你写 Node.js 后端的时候，根本不用考虑异步加载的问题，尽管放心用 require 同步导入，效率高还方便。
CMD 则主要面向浏览器端。早期前端没有官方的模块化方案，SeaJS 加上 CMD 规范，解决了不少大型前端项目的模块化难题。不过后来随着 ES6 模块的普及，CMD 用得越来越少了，但一些老项目里可能还能见到它的身影。
还有个细节，就是模块标识的处理。CommonJS 里的模块标识可以是相对路径（比如./utils）、绝对路径（比如 /usr/local/utils），或者是核心模块（比如 fs、path），Node.js 会按特定规则去查找模块文件。CMD 的模块标识规则和 CommonJS 类似，但因为运行在浏览器端，通常更依赖构建工具来处理路径，把模块打包成浏览器能识别的形式。
? CMD 模块化开发，这些技巧能少走弯路
虽然现在 CMD 用得不如以前多，但如果你接手了用 SeaJS+CMD 的老项目，掌握这些技巧能让开发效率翻倍。
首先，依赖声明要 “就近”。CMD 的核心理念是 “依赖就近，延迟执行”，所以写代码的时候，别把所有 require 都堆在模块最开头。比如你在模块中间某段逻辑里需要用到一个弹窗组件，那就在那段逻辑前面写 const Dialog = require ('./dialog.js')，而不是一上来就把所有可能用到的依赖都导入。这样做的好处是，只有当这段逻辑执行时，弹窗组件才会被加载，能减少初始加载的资源体积。
其次，正确处理 exports 和 module.exports。在 CMD 模块里，exports 是 module.exports 的一个引用，就像 CommonJS 里那样。如果你想导出一个对象，直接给 exports 添加属性就行，比如 exports.getName = function () { ...}。但如果你想导出一个函数或者类，就得用 module.exports，比如 module.exports = function () { ... }—— 千万别直接给 exports 赋值，比如 exports = function () { ... }，这样会断开它和 module.exports 的联系，导出会失败。
再者，避免循环依赖。循环依赖就是 A 模块依赖 B 模块，B 模块又依赖 A 模块，这种情况在复杂项目里很容易出现。CMD 处理循环依赖的方式和 CommonJS 类似，会返回未完成的模块对象。比如 A 模块里先导出一个 init 方法，然后 require B 模块；B 模块里 require A 模块时，只能拿到 A 模块已经导出的 init 方法，后续添加的属性可能拿不到。解决办法是尽量拆分模块，减少模块间的耦合，或者把依赖声明放在代码后面，等模块自身的核心内容导出后再加载依赖。
还有，用好模块的异步加载。CMD 里除了同步的 require，还有一个 require.async 方法，能异步加载模块。比如你需要在用户点击某个按钮后才加载一个大数据图表模块，就可以这么写：document.getElementById ('showChart').onclick = function () { require.async ('./chart.js', function (Chart) { new Chart (); }); }。这样图表模块不会在页面初始时加载，能加快首屏渲染速度。
别忘了配合构建工具使用。纯浏览器环境下，SeaJS 加载模块会发起很多 HTTP 请求，影响性能。实际开发中，通常会用 spm（SeaJS 的包管理工具）或者 webpack、gulp 等构建工具，把 CMD 模块打包成一个或多个合并文件，减少请求次数。打包的时候注意配置好模块路径，避免出现找不到依赖的问题。
最后，尽量保持模块的单一职责。一个 CMD 模块只做一件事，比如一个模块负责处理表单验证，另一个模块负责发送请求，这样不仅代码清晰，也方便复用和维护。别把一堆不相关的功能塞进同一个模块，不然模块会越来越臃肿，依赖关系也会变得混乱。
? 总结一下，别再搞混了
CMD 规范和 CommonJS 虽然都是 JavaScript 模块化方案，但定位和机制完全不同。CommonJS 是同步加载、加载即执行，适合服务器端；CMD 是按需加载、延迟执行，更适合浏览器端。
开发 CMD 模块时，记住依赖就近、正确导出、处理好循环依赖，再配合构建工具，就能发挥它的优势。虽然现在 ES6 模块已经成为主流，但了解这些历史上的模块化方案，能帮你更深入地理解 JavaScript 的模块化思想 —— 毕竟，新方案都是在旧方案的基础上发展来的。
【该文章由dudu123.com嘟嘟 ai 导航整理，嘟嘟 AI 导航汇集全网优质网址资源和最新优质 AI 工具】
