静态分析能可靠识别简单 require/module.exports 模式，但对动态路径、条件导出、__dirname 依赖和循环引用无法安全替换，必须人工校验；迁移后须验证 node 版本 ≥14.18.0、package.json 含 "type": "module"、第三方依赖真正支持 esm，并重点测试 import.meta.url 与 __dirname 的路径行为差异。
静态分析能自动识别 require 和 module.exports 模式，但无法 100% 安全替换——尤其涉及动态路径、运行时条件导出、__dirname 依赖或循环引用时，必须人工介入校验。
哪些 CommonJS 模式能被静态分析工具可靠识别
现代迁移工具（如 @codemod/cli + jscodeshift 插件、esm-codemod）对以下结构有较高准确率：
-
const x = require('foo')→ 可转为import x from 'foo'（若包支持默认导出）或import * as x from 'foo' -
const { a, b } = require('foo')→ 可转为import { a, b } from 'foo' -
module.exports = function foo() {}→ 可转为export function foo() {} -
exports.bar = 42→ 可转为export const bar = 42 -
module.exports = { foo, bar }→ 可转为export { foo, bar }（命名导出）或export default { foo, bar }（需判断是否被其他模块以默认方式消费）
哪些地方静态分析会“误判”或直接放弃
工具遇到这些情况通常跳过、报 warning 或生成注释标记，不强行改写：
- 动态
require('./' + name)：无法推断路径，保留原样或需手动改用import()动态导入 -
if (process.env.NODE_ENV === 'test') module.exports = mock：条件导出破坏静态性，必须人工拆分逻辑或改用构建时 define 注入 -
require('./utils/' + env + '/config.js')：路径拼接导致模块图断裂，工具无法 resolve，需先固化路径或重构为配置驱动 - 循环
require链（A → B → A）：ESM 在解析阶段就报错，工具会检测并提示，但不会自动解环——得靠人梳理依赖顺序、提取共享状态或改用事件/注入模式 - 使用
__dirname或__filename构造路径：静态分析能定位语句，但无法安全替换成fileURLToPath(import.meta.url)，因为上下文路径语义可能变化（比如被require的 CJS 文件里调用了它）
迁移后必须验证的三个关键点
即使所有代码被自动转换，也不代表 ESM 能跑通。重点检查：
- Node.js 版本是否 ≥14.18.0：低于此版本的
import.meta.url行为不一致，且部分package.json字段（如exports）不受支持 -
"type": "module"是否已写入根package.json：没加这行，.js文件仍按 CJS 解析；加了之后，所有.js默认是 ESM，除非显式用.cjs后缀 - 第三方依赖是否真正兼容 ESM：运行
npm ls node-fetch看是否混入 v2（CJS only），v3+ 才是 ESM；类似地检查lodash、axios等主流库的主入口是否已声明"type": "module"或提供exports字段
最常被忽略的是 import.meta.url 与 path.resolve(__dirname, ...) 的行为差异：前者返回 file:// URL，后者是操作系统路径字符串。哪怕只有一处日志写入、配置加载或模板读取依赖这个，就可能在迁移后静默失败。别只看编译通过，要真跑起来测路径操作。
