17370845950

ES6模块与CommonJS是运行于不同环境的两套系统：import/export为编译时静态声明，必须位于顶层；require为运行时同步调用，可动态使用但有缓存和循环引用陷阱；Node.js通过文件扩展名和package.json的"type"字段区分二者。

ES6 模块（import/export）和 CommonJS（require/module.exports）本质不是“两种写法选一个”，而是运行在不同环境、由不同加载器解析的两套系统——浏览器原生支持 import，Node.js 默认用 require，混用不报错但行为可能出人意料。

为什么 import 不能写在 if 里

import 和 export 是编译时静态声明，不是运行时语句。引擎在代码执行前就要分析依赖图，所以不允许条件导入、动态变量名或函数作用域内使用。

• import 必须位于模块顶层，不能包裹在 if、for 或函数中
• 想实现条件加载？用 import() 动态导入（返回 Promise），它是运行时的
• export 同理：不能出现在块级作用域，也不能用表达式计算导出名（如 export { [key]: value } 不合法）

if (condition) {
  import { foo } from './utils.js'; // ❌ SyntaxError
}

// ✅ 正确的动态导入
if (condition) {
  import('./utils.js').then(({ foo }) => foo());
}

CommonJS 的 require 可以随时调用，但有缓存陷阱

require 是同步执行、运行时解析的，可以写在任意位置，也支持拼接路径，但它的模块缓存基于 filename（含绝对路径），同一文件多次 require 返回同一个对象引用。

• 修改已 require 模块的导出属性，会影响所有已引入该模块的地方（因为是浅拷贝引用）
• require('./config.js') 和 require('./config') 在 Node.js 中可能命中不同文件（后者会依次尝试 .js、.json、.node）
• 循环引用时，CommonJS 返回当前已执行部分的 exports 对象，不是空对象也不是报错

// a.js
const b = require('./b');
console.log('a gets b.count:', b.count); // undefined（b 还没执行完 export）
exports.count = 1;

// b.js
const a = require('./a'); // 此时 a.exports 是 {}，但已有 a.count = undefined
exports.count = 2;

Node.js 中同时支持两种语法，但规则很具体

Node.js 从 v12 起支持 ES 模块，但启用方式取决于文件扩展名和 package.json 的 "type" 字段，不是靠 Babel 或打包工具模拟。

• 文件后缀为 .mjs → 强制 ES 模块，无视 "type"
• 文件后缀为 .cjs → 强制 CommonJS，无视 "type"
• 文件后缀为 .js → 看同级 package.json 的 "type": "module"（ESM）或 "type": "commonjs"（默认）
• import 中不能直接写 require('./x')，反之亦然；跨类型互引需用 createRequire 或 dynamic import()

// 在 .mjs 文件中想用 require？
import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const fs = require('fs');

打包工具（如 Webpack/Vite）掩盖了差异，但错误仍会暴露

它们把两种模块语法统一转成自己的一套运行时模块系统，所以开发时感觉“都能用”。但某些边界情况会暴露底层差异：

• import() 动态导入在 Webpack 中可被分割成独立 chunk，在 CommonJS 里没有对应机制
• Webpack 对 require.context 的处理只适用于 CommonJS 风格的批量引入
• Vite 开发服务器按原生 ESM 提供模块，遇到 require 会报 ReferenceError: require is not defined
• Tree-shaking 只对 export + import 生效，module.exports 导出的对象无法被安全剔除

真正要落地模块化，得先明确目标环境：纯浏览器项目优先用 import/export；Node.js 工具脚本若需 __dirname 或文件同步读取，CommonJS 仍更直接；混合项目必须统一 "type" 并避免跨风格直接引用——否则看似跑通，上线后某个路径解析失败或导出为空，问题很难复现。