为什么不将它用作 Javascript 的通用组件模式，包括浏览器执行的 Javascript？
乍一看，这似乎是对我目前正在从事的项目进行模块化的好方法，该项目由一个大型 Javascript 代码库和许多组件组成，其中一些组件相互交互。
最佳答案
CommonJS 绝对适用于浏览器，但有一些注意事项。 CommonJS 模块模式非常好(在我的偏见看来)，也是为 ECMAScript Harmony(计划的 JavaScript 语言的下一个版本)提议的模块系统的良好垫脚石。具体来说，Harmony 模块将无法访问全局(“窗口”)对象。
有些人声称 CommonJS 模块不适合浏览器的原因是，如果没有服务器端的帮助，它们无法通过 <script> 标签加载。例如，假设您有一个导出“convertToHTML”函数的 Markdown 库。然后你可以制作一个看起来像这样的模块:
var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
// do something then call convertToHTML
}
由于一些原因，这不能通过脚本标签工作(范围没有包装，所以 convertToHTML 会附加到窗口，通常不会定义 require 并且需要为每个模块单独创建导出) .
带有少量服务器端帮助的客户端库可以让它通过脚本标签轻松加载。或者，通过 XMLHttpRequest 加载脚本并执行 eval() 的客户端库也可以工作，尽管调试体验通常不太好。
目前一个相当合理的解决方案是 RequireJS，尽管它也是 CommonJS 成员之间争论不休的主题。 .使用 RequireJS，您可以像这样编写模块:
define(function(require, exports, module) {
var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
// do something then call convertToHTML
}
});
我们所做的就是在模块周围添加 define() 位。 (你也可以让服务器很容易地做到这一点，这样你甚至不需要手动输入定义部分)。
我个人现在已经在几个项目中使用过 RequireJS，并且发现它是一种无需服务器端位即可使用 CommonJS 模块的简单方法。还有许多其他解决方案，如果您不依赖于运行静态 JS 文件，标准的 CommonJS 模块是一个不错的选择。
(ObDisclaimer:我启动了 CommonJS 项目，所以我显然有偏见。)
关于javascript - 为什么只说 CommonJS 适用于非浏览器应用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4773298/