自研html校验工具是解决工程化中语义、可访问性及运行时一致性痛点的必要手段，需基于rehype生态构建ast级干预，并嵌入pre-commit、ide和构建流程实现问题前置拦截。
自研 HTML 工具在工程化落地中不是“锦上添花”，而是解决真实痛点的必要手段——尤其当项目已脱离纯静态阶段，但又不值得引入整套框架时。
为什么不能只靠 prettier + eslint 处理 HTML？
它们能格式化标签缩进、校验属性拼写，但对 HTML 的语义结构、可访问性（a11y）、运行时行为一致性无能为力。比如 <div onclick="handleClick()"> 不会报错，但违背现代组件化交互原则；<code><img> 缺少 alt 在 ESLint 中默认不检查，Prettier 也从不添加。
- HTML 是运行时载体，不是纯文本：工具需理解 DOM 构建逻辑（如
template、slot、shadow root边界） - 第三方库注入的 HTML（如 Cesium.js 动态生成的图层容器）无法被静态 lint 覆盖
- 团队约定的自定义约束（如禁止裸
<button></button>、强制data-testid）需定制规则，而非通用配置
自研 HTML 校验工具的关键能力设计
核心不是重造 parser，而是围绕 AST 做精准干预。推荐基于 rehype 生态构建，它用 hast（HTML AST）统一表示，插件可链式组合。
- 用
rehype-parse解析原始 HTML，避免正则匹配的脆弱性 - 编写自定义插件检测语义问题：例如遍历所有
<img>节点，检查node.properties.alt是否存在且非空字符串 - 集成
axe-core的轻量版规则，输出 WCAG 2.1 级别错误（如对比度不足、焦点顺序异常），但只在 CI 阶段触发，不侵入开发流 - 支持白名单机制：对已知第三方库生成的 HTML 片段（如
cesium-viewer容器）跳过检查，避免误报
如何让校验结果真正影响开发流程？
工具再准，不嵌入工作流就等于没用。重点不是“发现多少问题”，而是“让问题在发生前就被拦截”。
- 在
pre-commit钩子中调用 CLI：执行npx rehype --use ./plugins/a11y-check.js src/**/*.html，失败则中断提交 - VS Code 插件实时高亮：基于
rehype的 LSP 封装，对当前编辑文件做增量校验，错误直接标在行尾 - 与构建系统联动：Vite 或 Webpack 构建时启用
rehype-plugin-validate，若检测到严重问题（如缺失lang属性）则process.exit(1) - 输出机器可读报告（JSON）供 CI 显示趋势：不是只报“共 12 条警告”，而是按规则分组、标注首次出现位置、关联 PR 提交者
真正难的从来不是写出一个能跑的校验器，而是让每条规则都有明确的修复指引、每个错误都对应可落地的协作动作——比如检测到 <table> 未包裹 <code><caption></caption>，就自动建议补上语义化标题，而不是只抛出“accessibility.table-missing-caption”这种抽象码。
