建立闭环回溯体系：防止日常发布导致HTML代码质量下滑

HTML变脏的根源，在于缺少发布前的校验和发布后的快照比对机制。要解决它，需要html-validate做静态扫描、playwright抓取线上DOM做标准化后的diff，再把问题精准回溯到代码提交或CMS编辑者。——这才是闭环。

为什么每次发布后 HTML 会悄悄变脏？

你有没有发现，每次发布后，HTML代码就像被偷偷动过手脚？根本原因不在于开发者写代码不认真，而是缺乏自动化的“发布前校验 + 发布后比对”机制。前端构建、CMS渲染、A/B实验注入、第三方SDK插入……这些环节都可能往最终HTML里塞进冗余的div、缺失的alt、错位的aria-*属性，或者绕过ESLint的内联脚本。它们不会引发构建错误，却会让可访问性、SEO和后继维护持续退化。

所以结论很明确：单靠人工Code Review或上线后肉眼检查，根本守不住HTML质量底线。必须把HTML当作可测试、可快照、可diff的一等公民来对待。

用 html-validate 做发布前静态扫描

相比传统的tidy或W3C Validator，html-validate在工程化集成上更得心应手。它支持自定义规则、可以忽略特定模板片段，还能输出机器可读的结果。

• 安装：npm install --sa ve-dev html-validate
• 配置.htmlvalidate.json，重点启用valid-attr（防拼错属性）、require-alt（强制图片替代文本）、no-inline-style（拦截内联CSS）
• 在CI中加入：npx html-validate "src/**/*.html" "public/**/*.html"，失败即阻断发布
• 注意：对SSR模板（如index.ejs）需先构建出真实HTML再校验，不能直接扫源模板文件

用 playwright 抓取线上页面做 HTML 快照比对

静态扫描管不住运行时注入，所以必须捕获真实用户看到的DOM。用playwright启动无头浏览器，导出标准化后的HTML（移除动态ID、时间戳、随机class），再与基线快照做diff。

• 关键步骤：用page.content()获取完整HTML → 用parse5重序列化（抹平格式差异）→ 去除data-testid、id、style等非语义属性 → 生成哈希存档
• 比对逻辑建议放在发布后5分钟触发，避免CDN缓存未刷新导致误报
• 一个典型的diff差异点：被运行时注入覆盖成了（拼写错误）

闭环的关键：让问题回流到具体提交者

光有报警还不够。HTML异常必须关联到代码变更的源头：

• 把快照比对失败的页面URL和异常HTML片段，自动写入PR comment，并附带git blame定位到最近修改该路由模板的提交
• 对CMS页面，记录最后编辑人邮箱，触发企业微信/钉钉告警，附上修复指引链接（例如：“请检查字段映射是否漏配alt_text”）
• 禁止设置“忽略此页”的全局开关——每个例外都得走审批并写明原因，否则例外会指数级蔓延

真正难的不在于工具链的搭建，而在于让每一次git push都带着HTML质量承诺。而整个环节中最容易被跳过的，是线上快照的“标准化清洗”这一步——少做一次属性过滤，diff结果就全是噪音。