不能在编译器插件中通过html语法树实现自动化代码重构，因为clang、babel、typescript compiler等主流工具仅处理各自语言（c/c++/js/ts），不解析html；html是标记语言，无编译器前端和插件机制，真正可行路径是使用专用html解析器如parse5或cheerio，或框架专属ast（如@vue/compiler-dom）。
不能在编译器插件中通过 HTML 语法树（AST）实现自动化的代码重构——因为主流编译器（Clang、LLVM、Babel、TypeScript Compiler）根本不解析 HTML。
HTML 没有“编译器插件”这个概念
Clang 插件只处理 C/C++/Objective-C；Babel 插件只处理 JavaScript/JSX/TypeScript；TS 的自定义 transformer 也仅限于 TS/JS。HTML 是标记语言，不是编译型语言，没有编译器前端、没有 IR、没有插件加载机制。所谓“HTML 编译器插件”，本质是混淆了构建工具链层级。
- 你看到的
html-webpack-plugin或vite-plugin-html是构建时的字符串/AST 处理器，不是编译器插件 -
prettier的parser-html是独立解析器，不依赖任何编译器的 AST 接口 - Monaco/CodeMirror 的格式化逻辑走的是
prettier.format()，不是 Clang 的ASTConsumer
想对 HTML 做自动化重构，该用什么工具
真正可行的路径是：用专用 HTML 解析器 + 转换器，而非编译器插件。关键不是“能不能”，而是“谁负责解析、谁暴露 API、谁生成结果”。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 选
parse5或cheerio：轻量、浏览器/Node 兼容、API 直观，适合批量重写属性、移动节点、增删 class - 避免手写正则：
<div class="foo"> 和 <code><div class="foo"> 结构等价，但正则极易漏匹配换行或空格 <li>若需类型安全和深度语义（如识别 Angular 模板语法、Vue 指令），用 <code>@angular/compiler或@vue/compiler-dom提供的 AST 接口，它们才是专为框架模板设计的“重构友好型 AST” - 输入层：Clang 的
FrontendAction只接受.c/.cpp；Babel 的transformSync()默认拒绝.html文件，除非你手动注册 parser（但 parser 返回的 AST 不是 Babel 的File类型，后续 traverse 会报path.node is undefined - 作用域层：HTML 没有变量作用域、闭包、TDZ 这些概念，
path.scope.hasBinding()这类 Babel 特有逻辑直接无意义 - 输出层：Clang 的
Rewriter只能插入/替换 C++ token；Babelgenerator输出 JS，无法保证生成合法 HTML 缩进或属性顺序
为什么硬塞进 Clang/Babel 会失败
强行把 HTML 塞进编译器插件，会在三个层面断掉：
HTML 重构真正的复杂点不在 AST 遍历本身，而在边界判定：自闭合标签是否加斜杠、<p></p> 是否需要显式闭合、CDATA 区块内能否执行 JS 替换、注释里是否含待跳过的模板语法——这些都得靠专用解析器的 grammar 规则兜底，不是靠“通用 AST 插件架构”能覆盖的。
