必须通过ast精准识别regexpliteral、newexpression和callexpression三类正则节点，结合模式与标志做安全升级；检测灾难性回溯等风险并分级告警；生成语义等价替代方案，规避动态构造与工程陷阱。
不能靠字符串替换或正则去改正则——复杂正则常嵌在模板字符串、动态拼接、变量赋值甚至函数返回值中，语义依赖上下文。必须通过 AST 定位真实 RegExp 字面量或 new RegExp() 调用节点，再结合模式内容、标志、使用方式做安全升级。
精准识别所有正则表达式节点
遍历 AST 时需覆盖三类真实正则来源：
-
RegExpLiteral：如
/\d{3}-\d{2}-\d{4}/g，直接提取pattern和flags -
NewExpression 节点中 callee 为
RegExp：如new RegExp(patternStr, 'i')，需检查参数是否为字面量（字符串/模板）或可静态求值的表达式 -
CallExpression 中 callee 为
RegExp（无new）：如RegExp(str, 'u')，同样需确保参数可控
跳过任何含变量、函数调用、await 或用户输入拼接的正则构造——这些无法静态分析安全性，必须人工介入。
检测常见不安全模式并分级告警
对提取出的正则源字符串，用专用规则引擎（如 safe-regex 或自研有限自动机分析器）扫描以下风险：
-
灾难性回溯（Catastrophic Backtracking）：如
(a+)+b、(\w+\s?)+类嵌套量词组合，触发 O(2ⁿ) 匹配时间 -
过度宽泛匹配：如
.*出现在非锚定位置，易导致意外长匹配或拒绝服务 -
缺失 Unicode 标志但处理多语言文本：含中文、emoji 等却无
u标志，导致字符边界错误 -
危险标志组合：如
g+y（粘性）混用不当，或m在未锚定行首时造成逻辑偏差
按风险等级标记：阻断级（必须改）、建议级（推荐优化）、观察级（暂不处理但记录）。
生成语义等价的安全替代方案
重构不是简单加 ^$ 或删 g，而是保持原意图前提下收紧行为：
- 将
/(a+)+b/拆为两步：/a+/先提取候选段，再用.includes('b')或精确子串校验 - 把模糊的
/.*error/i替换为锚定且明确的/\b(error|fail|reject)\b/i - 对需要 Unicode 支持的
/\p{L}+/，强制补u标志，并验证环境支持（Node ≥10.0 / Chrome ≥64） - 若原正则用于
String.prototype.replace()且含捕获组，新正则必须保留组数与顺序，否则回调函数match[1]会错位
用 @babel/types 构造新节点：t.regExpLiteral(safePattern, safeFlags) 或 t.newExpression(t.identifier('RegExp'), [t.stringLiteral(safePattern), t.stringLiteral(safeFlags)])，不拼字符串。
规避工程落地陷阱
真实项目中容易踩坑的点必须显式防护：
- 跳过
node_modules、测试文件（**/*.test.js）、构建产物目录 - 若正则出现在
import()动态导入路径、eval()内部或带注释标记// no-replace-regexp，直接跳过 - TS 项目中若正则赋值给带类型声明的变量（如
const re: RegExp = /.../;），需确保新节点仍满足类型约束 - 替换后保留原节点的
leadingComments和trailingComments，避免文档丢失
每次替换调用 path.replaceWith(newNode) 后立即 path.stop()，防止子节点重复处理。
