html变脏的根本原因是缺乏发布前校验与发布后快照比对机制，需用html-validate做静态扫描、playwright抓取线上dom标准化后diff，并将问题精准回溯至代码提交或cms编辑者。
为什么每次发布后 HTML 会悄悄变脏？
根本原因不是人没写好，而是缺乏自动化的“发布前校验 + 发布后比对”机制。前端构建、CMS 渲染、A/B 实验注入、第三方 SDK 插入等环节，都可能在最终 HTML 中混入冗余 div、缺失 alt、错位 aria-* 属性、或绕过 ESLint 的内联脚本——这些不会报构建错误，但会让可访问性、SEO 和后续维护持续退化。
关键判断：单靠人工 Code Review 或上线后肉眼检查，无法守住 HTML 质量底线；必须把 HTML 视为可测试、可快照、可 diff 的一等公民。
用 html-validate 做发布前静态扫描
它比 tidy 或 W3C Validator 更适合工程化集成，支持自定义规则、忽略特定模板片段，并能输出机器可读结果。
- 安装：
npm install --save-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 差异点：
<button aria-label="submit"></button>→<button aria-lable="submit"></button>（拼写错误被 runtime 注入覆盖了原始代码）
闭环的关键：让问题回流到具体提交者
光有报警没用。HTML 异常必须关联到代码变更源头：
- 把快照比对失败的页面 URL 和异常 HTML 片段，自动写入 PR comment，附带
git blame定位到最近修改该路由模板的提交 - 对 CMS 页面，记录最后编辑人邮箱，触发企业微信/钉钉告警，并附上修复指引链接（比如：“请检查字段映射是否漏配
alt_text”） - 禁止设置“忽略此页”的全局开关——每个例外都得走审批并写明原因，否则例外会指数级蔓延
真正难的不是工具链搭建，是让每次 git push 都带着 HTML 质量承诺；而最容易被跳过的，是线上快照的「标准化清洗」这一步——少做一次属性过滤，diff 就全是噪音。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
