CommonJS和ES6模块怎么选？

CommonJS与ES6模块并非简单二选一的技术偏好，而是由Node.js版本、package.json的"type"字段、文件后缀（.js/.cjs/.mjs）、构建工具（Webpack/Vite）配置及目标运行环境（浏览器/服务端/SSR）共同决定的动态适配问题——写错一句import或require就可能在开发时正常、构建时报错、上线后失效；本文直击真实项目中最易踩坑的模块解析逻辑差异，帮你从“凭感觉写”转向“看配置定语法”，快速定位跨环境模块异常根源。

CommonJS 和 ES6 模块（import/export）不是“选一个用”，而是由运行环境和构建工具共同决定的——你写什么，得看 Node.js 版本、打包器配置、目标平台是否支持动态 import()，以及是否要服务端渲染或热更新。

Node.js 里怎么判断该用 require 还是 import

Node.js 从 v12 开始实验性支持 ES 模块，v14.13+ 默认启用，但行为仍受文件扩展名和 package.json 的 "type" 字段控制：

• 如果 package.json 里写了 "type": "module"，所有 .js 文件按 ES 模块处理，require() 会报 ERR_REQUIRE_ESM
• 如果没写 "type" 或设为 "commonjs"，默认走 CommonJS，此时用 import 会报 Unexpected token 'export'（除非是 .mjs 后缀）
• .cjs 和 .mjs 后缀优先级高于 "type"：前者强制 CommonJS，后者强制 ES 模块

所以别硬记规则，先查 package.json 里的 "type"，再看文件后缀——这是最稳的判断依据。

Webpack/Vite 等打包器里 import 为什么有时能混用 require

打包器在构建阶段会把模块语法统一转译，并注入自己的模块加载逻辑。这意味着：

• import fs from 'fs' 在 Webpack 中会被忽略（因为浏览器没有 fs），而 require('fs') 会直接报错或被替换成空对象
• Vite 开发时原生支持 import，但遇到 require 就会提示 “Dynamic require is not supported” —— 它不模拟 CommonJS 运行时
• Webpack 默认兼容两者，但开启 experiments.topLevelAwait: true 后，CommonJS 模块里不能有顶层 await，否则解析失败

简单说：开发时按项目配置写，别指望“写啥都能跑”；上线前看打包产物里是否真生成了 __webpack_require__ 或 import.meta.url 这类标记，才能确认模块系统落地方式。

浏览器环境只认 import，但 import() 动态加载要注意什么

浏览器原生只支持 import 语句和 import() 函数，不支持 require。但动态导入有几个实际限制：

• import('./foo.js') 返回 Promise，路径必须是字符串字面量或模板字符串（不能是变量拼接），否则 Webpack/Vite 无法静态分析
• Chrome 89+ 支持 import.meta.url 获取当前模块 URL，但旧版 Safari 不支持，要用 document.currentScript?.src 替代
• 服务端渲染（如 Next.js）中，import() 在服务端执行会失败，需加 if (typeof window !== 'undefined') 判断

常见错误是把 import() 当成 require() 的平替，在循环里传入变量路径，结果构建时报 “Cannot statically analyze import()”。

真正麻烦的不是语法选哪个，而是跨环境时模块解析逻辑不一致：比如同一份代码在 Vite 开发服务器里跑得好好的，放到 Node.js CLI 工具里就因 "type": "module" 报错；或者 Webpack 打包后发现某个库的 require.resolve 被删掉了，因为它的 CommonJS 分支没被识别到。这些边界问题，光看文档很难覆盖全，得靠 node --experimental-modules、vite build --debug 或 Webpack 的 stats: 'verbose' 实际看模块图。

今天关于《CommonJS和ES6模块怎么选？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！