使用AST静态分析编写团队规范的JS自动混淆插件

手动实现AST混淆插件：从原理到实践

分享一下个人经验：当团队规范涉及细粒度的命名约束、作用域感知的变量替换，以及禁止混淆特定模式（比如 __DEV__ 或 process.env）时，直接操作 ESTree AST 比使用 jscodeshift 这种高阶封装要可控得多。为什么呢？jscodeshift 的 transform 模式默认不保留原始节点位置、注释和空格，很容易破坏可调试性。但自己上手操作 ESTree 树，感觉就完全不同了——你能够精确控制每个 Identifier 是否重命名、是否跳过 ObjectPattern 中的解构名、是否保留 ImportSpecifier 的本地绑定名。这些细节在高阶封装里，往往被当成“副作用”直接忽略了。

为什么直接操作 estree AST 节点比用 jscodeshift 更可控

这背后的道理其实很简单。你想要精细控制混淆流程，就必须能直接对话AST节点本身。手工遍历 estree 树能做到的事情，jscodeshift往往望尘莫及。

实操建议：

• 用 @babel/parser 解析源码时，sourceType: 'module' 必须显式指定——否则 import 语句会直接解析失败
• 遍历部分，用 @babel/tra verse 而不是手写递归：它会自动帮你处理好 Scope 链、bindings 映射、以及 skipKeys 防止重复进入子树等难题
• 混淆前，先把所有可混淆的 Identifier 类型收集全：局部变量（VariableDeclarator.id）、函数参数（FunctionExpression.params）、for 循环中的 init 变量——但务必排除 ClassDeclaration.id 和 ExportNamedDeclaration.specifiers，不然导出名会丢失

Identifier 重命名时如何避免作用域污染和引用失效

混淆不是随机换名那么简单，它的核心法则是什么？「同作用域内唯一 + 跨作用域可区分 + 不覆盖保留字」。直接用 Math.random().toString(36).slice(2) 生成名，很快你就会遇到父子作用域冲突——父级变量被同名子级覆盖了；而全局统一计数器，又会让不同文件的同名变量映射到相同的混淆名，模块隔离直接被破坏。

实操建议：

• 为每个 Scope 实例单独维护一个 nameMap: Map，键是原始名，值是混淆后的名字
• 操作 Identifier 节点时，先调用 path.scope.getBinding(identifier.name) 获取绑定对象，然后根据 binding.kind 区分：'local' 或 'param' 处理，'module' 和 'hoisted' 跳过
• 生成混淆名时加上作用域哈希前缀，例如 `_a${hash(scope.path.node.loc.start)}`，有效避免跨文件碰撞
• 这点很重要：用 path.replaceWith(...) 而不是直接改 node.name——否则 Scope 不会重新分析引用关系，后续 binding.referencePaths 会全部错乱

如何安全跳过团队明确定义的「不可混淆区域」

常见的做法是用正则去匹配字符串字面量或注释来跳过，但这样其实不太可靠。在 AST 层面，更稳妥的方式是识别节点类型与上下文语义。比如 console.log('xxx') 里的 'xxx' 是 Literals，不该进混淆逻辑；而 const API_URL = 'https://api.example.com' 中的 API_URL 是变量名，需要混淆——但若该变量被标记了 /* @no-obfuscate */，就得拦截它。

实操建议：

• 在 enter 钩子中检查 path.node.leadingComments，匹配 /@no-obfuscate/i，匹配就执行 path.skip()
• 遇到 MemberExpression（如 window.location.href），检查 object.name === 'window' 且 property.name === 'location'，直接跳过整条路径
• 对于 CallExpression，若 callee.name === 'require' 或 callee.type === 'Import'，不进入其 arguments 子树
• 特别注意 TemplateLiteral 中的 expression：里面可能藏着变量引用，必须单独判断是否属于可混淆作用域，不能因为外层是模板字面量就一并放过

混淆后代码体积增大或执行报错？重点检查这三处

混淆插件上线后，最常见的坑有两个：一是压缩工具（如 terser）没法进一步压缩混淆后的长变量名，导致产物体积不降反增；二是某些运行时环境（想想微信小程序引擎），对过短的标识符（如 _a）有兼容性限制，直接给你抛个 SyntaxError: Unexpected token。

实操建议：

• 混淆名长度控制在 2–4 字符，用固定字符集（如 'abcdefghijklmnopqrstuvwxyz'）循环生成，避开 0、O、l 等容易混淆的字符
• 混淆之后，立即用 @babel/generator 输出代码，传入 compact: true 和 jsescOption: { minimal: true }，减少转义开销
• 必须要在混淆流程末尾插入一次 path.stop()，防止 tra verse 因节点替换触发了二次遍历，导致同一个 Identifier 被重命名两次——想象一下从 foo → _a → _b 的悲剧

我得强调，真正难的不是生成乱码名，而是让每个 Identifier 在正确的作用域里被正确识别、正确跳过、正确替换——漏掉一个 catch 块里的错误参数，或者误混淆了 export { foo as bar } 里的 bar，线上就可能静默失败。这才是真正的效果之所在。