答案是：通过检测 typeof process === 'object' && typeof require === 'function' && typeof module === 'object' && module.exports !== undefined，并排除 ESM 模式（如无 .mjs 后缀、"type": "module" 等），可判断当前环境原生支持 CommonJS。
CommonJS 本身不是浏览器原生支持的规范，它是 Node.js 运行时定义的一套模块系统。所以“当前执行环境是否原生支持 CommonJS”这个问题，本质上是在问：当前代码是否运行在 Node.js 环境中，且未启用 ESM 模式（即默认 CommonJS 模式）。
看 process 对象是否存在且是 Node.js 风格
CommonJS 是 Node.js 的默认模块系统，而 process 是 Node.js 全局对象，浏览器中不存在（除非被 polyfill 或误注入）。可安全用于基础判断：
typeof process !== 'undefined' && process.release && process.release.name === 'node'- 更简洁常用写法：
typeof process === 'object' && process?.versions?.node
检查 module 和 require 是否可用且行为符合预期
仅靠 process 不够严谨（比如某些打包工具或测试环境会模拟它）。进一步验证模块系统是否为 CommonJS：
typeof require === 'function' && typeof module === 'object' && module?.exports !== undefined- 避免误判：ESM 环境下
require会直接报ReferenceError，但若已进入运行时且没抛错，基本可确认是 CommonJS 上下文
排除 ESM 主动启用的情况
Node.js 中即使有 process 和 require，也可能因以下原因实际运行在 ESM 模式，此时 CommonJS 行为受限或不可用：
立即学习“Java免费学习笔记（深入）”；
- 文件扩展名为
.mjs -
package.json中设置了"type": "module" - 启动时加了
--input-type=module或通过import()加载 - 因此，稳妥做法是补充检查：
!module?.children && !module?.parent && module?.id === '.'（常见于顶层 CommonJS 模块），但更实用的是结合文件后缀或配置上下文判断
不建议依赖 window / self / document 判断
有人用 typeof window === 'undefined' 来“反推”是 Node.js，这不可靠：
- Worker、Deno、Bun、Electron 渲染进程等环境也无
window，但不等于支持 CommonJS - 服务端 Web 框架（如 Next.js、Nuxt）可能在 Node.js 中运行但禁用
require（如 Edge Runtime） - 真正要检测的是模块系统能力，而非宿主环境类型
