最可靠、可落地的批量迁移方式是用静态分析工具扫描并重写选择器调用，核心是基于AST精准定位目标节点后按新API生成等效代码。
直接用静态分析工具扫描并重写选择器调用，是目前最可靠、可落地的批量迁移方式。核心不是“替换字符串”，而是理解 AST 结构后精准定位目标节点，再按新 API 规范生成等效代码。
识别老旧选择器调用模式
老旧项目中常见的选择器操作往往有固定语法特征，比如：
-
jQuery 风格：
$(".btn").click(...)、$(selector).find("input").val() -
原生封装函数：
getElementsByClassName("nav-item")、querySelectorAll("[data-role='tab']") -
自定义工具类方法：
UI.select("#modal").show()、DomUtil.find(".card-header")
静态分析需基于 AST（抽象语法树）识别这些调用链，而非简单正则匹配——否则容易误伤注释、字符串字面量或模板字符串中的伪选择器。
构建可配置的迁移规则引擎
真正可复用的方案，必须支持规则配置，例如：
- 将
document.querySelectorAll(".item")→document.querySelectorAll(".item")（保留不变，仅加类型标注） - 将
$("#header").text("New")→document.getElementById("header")?.textContent = "New" - 将
UI.toggle(".sidebar", "open")→document.querySelectorAll(".sidebar").forEach(el => el.classList.toggle("open"))
规则应包含：源表达式模式（AST 节点类型 + 属性约束）、目标模板（支持变量插值）、适用范围（文件路径白名单/黑名单）、是否自动插入 polyfill 检查（如 closest() 兼容性）。
集成到开发与 CI 流程中
迁移不是一次性动作，而是渐进过程。建议分三步落地：
- 扫描报告阶段：运行分析器，输出 HTML 报告，列出所有待迁移点、风险等级（如是否含动态拼接 selector）、建议替换方式
- 安全重写阶段：启用 --write 模式，只改明确匹配且无副作用的调用；对含变量、eval、模板字符串的复杂 case 标记为“需人工确认”
-
CI 卡点阶段：在 PR 流程中加入检查，禁止新增旧选择器调用（如禁止
$("或getElements出现在新增 JS 文件中）
推荐工具链组合
不依赖单一工具，而是分层协作：
-
解析层：使用
@babel/parser或acorn构建 AST，兼容 ES2020+ 和 JSX -
遍历/重写层：用
jscodeshift（成熟、社区规则丰富）或ast-grep（轻量、pattern-first、适合快速验证） -
上下文增强层：结合 TypeScript 类型信息（如有），避免把
const $ = customQuery误判为 jQuery - 验证层：迁移后自动运行 ESLint + 自定义规则，检测残留的旧模式或潜在的 NodeList/HTMLCollection 使用错误
实际项目中，一套配置好的 jscodeshift 脚本 + GitHub Action，就能在 10 分钟内完成中型前端项目的首轮识别与安全替换。
