CommonJS和ES模块的选择取决于运行环境与构建工具配置：Node.js中需查package.json的"type"字段和文件后缀；Webpack/Vite等打包器会转译模块语法；浏览器仅支持import/import()，且动态导入路径须为字面量。
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
打包器在构建阶段会把模块语法统一转译，并注入自己的模块加载逻辑。这意味着：
立即学习“Java免费学习笔记（深入）”；
-
import fs from 'fs'在 Webpack 中会被忽略（因为浏览器没有fs），而require('fs')会直接报错或被替换成空对象 - Vite 开发时原生支持
import，但遇到require就会提示 “Dynamicrequireis 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' 实际看模块图。
