当前位置：首页 > 文章列表 > 文章 > 前端 > JavaScript模块化方法及AMD与CommonJS对比

JavaScript模块化方法及AMD与CommonJS对比

2026-02-08 10:03:30 0浏览收藏

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《JavaScript模块化实现方式及AMD与CommonJS区别》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

JavaScript模块化由运行环境决定：浏览器早期用异步AMD，Node.js用同步CommonJS，现代统一采用原生支持的ES Module；三者机制不同，不可混用，强行桥接易出错。

javascript模块化如何实现_AMD与CommonJS有何区别？

JavaScript 模块化不是“选一个就完事”的问题，而是运行环境决定模块系统：浏览器端早期靠 AMD（如 RequireJS），Node.js 用 CommonJS（require/module.exports），现代则统一走向 ES Module（import/export）。两者本质不同，不能混用，强行桥接容易出错。

AMD 是异步加载的浏览器方案，依赖前置声明

AMD 的核心是解决浏览器中脚本按需、异步加载的问题。它不依赖文件系统路径，而是靠配置或约定来映射模块名到 URL，所有依赖必须在定义时显式列出。

define 函数第一个参数是依赖数组，第二个是工厂函数，执行时机由加载器控制，**不保证顺序执行**
模块导出靠工厂函数的返回值，不是赋值给某个对象属性
常见错误：在 define 工厂函数里直接调用 require('./x') 动态加载——这属于“运行时依赖”，AMD 要求“编译时可分析”，否则打包工具（如 r.js）无法处理
典型写法：

define(['./math', 'jquery'], function(math, $) {
  return {
    add: function(a, b) { return math.add(a, b); }
  };
});

CommonJS 是同步读取的 Node.js 方案，依赖即刻执行

Node.js 的 require 是同步阻塞式调用，基于真实文件路径查找，模块加载后立即执行，导出结果缓存在 require.cache 中。这意味着：

require 可以出现在任意位置（条件判断、循环内），但实际仍会在模块顶层被提升并预执行（v14+ 有部分优化，但行为不变）
module.exports 和 exports 不是引用关系，直接赋值 exports = {...} 会断开与 module.exports 的连接，导致外部 require 得到空对象
无法原生支持循环依赖的“部分导出”：A require B，B require A，若 A 在导出前就调用了 B 的方法，B 看到的是 A 的 module.exports 初始空对象（除非 A 提前赋值）
典型写法：

const fs = require('fs');
const math = require('./math');

function calc() {
  return math.add(2, 3);
}

module.exports = { calc };

AMD 和 CommonJS 不能直接互通，requirejs 的 define/require 不是 Node 的 require

看到 require('./xxx') 就以为是 CommonJS？不一定。RequireJS 的 require 是 AMD 规范下的异步加载函数，和 Node 的同步 require 完全不同机制。常见混淆点：

用 Webpack 打包时设 target: 'node'，却写了 define([...], ...) —— Webpack 会忽略它，当作普通函数调用，不会触发 AMD 加载逻辑
在 Node 里安装 requirejs npm 包并调用 requirejs.define，并不能获得 CommonJS 行为；它只是把 AMD 运行时搬进了 Node，模块路径解析、缓存、执行模型仍是 AMD 的
想让 AMD 模块在 Node 运行？得用转换工具（如 amdefine）或打包成 UMD，而不是改几行 require

现在该用哪个？优先 ES Module，兼容场景再考虑适配

import/export 是语言级标准，浏览器和 Node 都已原生支持（Node 需 .mjs 或 "type": "module"）。它的静态分析能力远超 AMD/CommonJS，Tree-shaking、循环依赖处理、顶层 await 都更可靠。

不要为了兼容老 IE 去写 AMD —— 用 Babel + Webpack 转译 ES Module 更可控
Node 项目别再写 module.exports 了，除非要支持 v12 以下；exports 对象可以保留，但导出应统一用 export default 或具名 export
最大的坑：在 package.json 里写了 "type": "module" 后，所有 .js 文件都必须用 ES Module 语法，require() 会直接报 ERR_REQUIRE_ESM

模块系统不是语法糖，它绑定着加载时机、作用域隔离、缓存策略和错误边界。选错方案，后期迁移成本远高于初期多写几行配置。

终于介绍完啦！小伙伴们，这篇关于《JavaScript模块化方法及AMD与CommonJS对比》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！