JavaScript模块化通过拆分代码解决全局污染和依赖问题，CommonJS（运行时同步、require/module.exports、Node.js早期标准）与ES模块（编译时静态、import/export、浏览器及现代Node原生支持）在加载时机、语法、环境及导出机制上存在本质差异。
JavaScript 模块化是把代码拆分成独立、可复用的单元，解决全局污染和依赖管理问题。CommonJS 和 ES 模块（ESM）是两种主流方案，核心差异在加载时机、语法、运行环境和导出/导入机制上。
CommonJS：运行时同步加载，Node.js 早期标准
CommonJS 是 Node.js 在 ES6 之前采用的模块系统，基于 require() 和 module.exports，所有操作都在代码执行时完成。
- 模块是同步加载的，适合服务端（文件 I/O 快），但不适用于浏览器原生环境（会阻塞页面渲染）
- 每个模块有独立作用域，module.exports 是模块对外暴露的唯一出口，exports 是它的快捷引用（但不能直接赋值，否则会断开引用）
- 支持动态导入，比如 require(condition ? './a' : './b')，路径可以拼接、变量替换
- 模块被缓存：同一模块多次 require 返回的是同一个对象引用，修改导出对象会影响所有引用处
ES 模块：编译时静态分析，浏览器与现代 Node.js 原生支持
ES 模块是 ECMAScript 官方标准（ES2015 起），使用 import/export 语法，必须在顶层作用域声明，且解析发生在代码执行前。
- 导入导出是静态的：路径必须是字符串字面量，不能动态拼接（如 import('./' + name) 需用 import() 动态函数，返回 Promise）
- 模块是单例且实时绑定：导出的是绑定关系（live binding），不是值拷贝；如果模块内部修改了导出的变量，所有导入处都能看到更新
- 默认导出（export default）和命名导出（export const x = 1）可共存；导入时可用默认导入（import foo from './foo'）、命名导入（import { x, y } from './foo'）或混合方式
- ESM 在 Node.js 中需通过 .mjs 后缀、package.json 中设置 "type": "module" 或命令行加 --experimental-modules（旧版本）启用
关键行为对比：一个例子看本质区别
假设 counter.js 导出一个递增计数器：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
counter.js（CommonJS）let count = 0;<br>module.exports = () => ++count;counter.js（ESM）
let count = 0;<br>export const inc = () => ++count;
在另一个文件中分别引入两次：
- CommonJS：两次 require('./counter') 得到两个独立函数，各自维护一份 count（闭包私有）→ 实际是两个模块实例
- ESM：两次 import { inc } from './counter' 引入的是同一个模块实例，共享 count 变量 → 修改一处，处处可见
互操作性：Node.js 中如何混用两者
Node.js 从 v12 起支持双模式共存，但需注意规则：
- .cjs 文件强制为 CommonJS，.mjs 或 "type": "module" 的 package 默认为 ESM
- ESM 中可用 import { createRequire } from 'module'; const require = createRequire(import.meta.url); 来调用 CommonJS 模块
- CommonJS 中不能直接 require() ESM 文件（会报错），但可通过 await import('./esm.mjs') 动态加载（返回 Promise）
- 推荐新项目统一用 ESM；迁移老项目时，优先将工具类、配置类模块转为 ESM，保留业务逻辑层兼容性
