JavaScript模块化应按环境、目标和交互选择ESM或CommonJS：浏览器优先ESM，Node.js需看版本；前端项目统一用ESM以支持tree-shaking；混合使用时注意互操作限制；npm包建议双格式发布。
JavaScript模块化是把代码按功能拆分成独立、可复用的单元，每个单元封装自身逻辑、明确对外接口。ES Module（ESM）和CommonJS是两种主流实现方式，选择哪个不取决于“哪个更好”，而要看运行环境、构建工具链和协作规范。
看运行环境：浏览器优先选ESM，Node.js需看版本和配置
现代浏览器原生支持 import/export，无需编译即可运行 ESM 文件（需用 <script type="module"></script>）。Node.js 从 v12.20+ 开始稳定支持 ESM，但需满足以下任一条件：
– 文件扩展名为 .mjs
– 或在 package.json 中声明 "type": "module"
– 或通过命令行参数 --input-type=module 显式启用
若项目仍需兼容老版 Node（如 v10 或某些企业内网环境），CommonJS 是更稳妥的选择。
看工程目标：前端项目基本统一用ESM
所有主流构建工具（Vite、Webpack、Rollup、esbuild）默认以 ESM 为输入标准。ESM 的静态结构让 tree-shaking 成为可能，能自动剔除未使用的导出代码，显著减小打包体积。比如你只用了 Lodash 的 debounce，ESM 下其余函数不会被打包进去；而 CommonJS 因为动态加载特性，工具无法安全判断哪些导出没被用到，往往整包引入。
另外，ESM 支持顶层 await、动态 import() 实现路由懒加载，这些能力在前端工程中已是标配。
看模块交互：混合使用时要注意互操作限制
Node.js 允许在 ESM 文件中用 import 加载 CommonJS 模块（会自动包装成命名空间对象），但反过来——在 CommonJS 中用 require() 加载 ESM 文件——会直接报错（ESM 不支持同步 require）。
常见陷阱包括：
– 把 exports = { fn } 当作合法写法（实际会切断与 module.exports 的引用，导致导出为空）
– 在 ESM 中把 import 写进 if 或函数里（语法错误，必须顶层）
– 误以为 ESM 导入的是值拷贝（其实是实时绑定：原模块改了，导入处也会变）
看 npm 发布：建议同时提供 CJS 和 ESM 双格式
面向开源的 npm 包，推荐采用“双入口”策略：
– main 字段指向 CommonJS 入口（如 dist/index.js），兼容旧环境
– module 或 exports 字段指向 ESM 入口（如 dist/index.mjs），供现代工具优化
构建时可用 Rollup 或 esbuild 同时输出两套产物。这样既不丢兼容性，又不牺牲前端性能。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
