HTML质量下滑源于发布链路缺两道自动门：发布前用html-validate静态扫描（配valid-attr、require-alt、no-inline-style规则，CI失败阻断），发布后用Playwright抓线上DOM快照比对（需标准化清洗后哈希比对），问题精准回流至提交者。
HTML质量下滑不是“写得不好”，而是发布链路里缺了两道自动门：发布前没拦住问题，发布后没比对出变化。光靠人工 Review 或上线后肉眼检查，根本守不住底线。
用 html-validate 做发布前静态扫描
它不是 W3C 验证器的替代品，而是工程化集成的轻量级守门员——能配规则、能忽略模板片段、能输出 JSON 供 CI 解析。
- 安装后必须配
.htmlvalidate.json，重点启用："valid-attr"（防拼错属性）、"require-alt"（强制图片替代文本）、"no-inline-style"（拦截内联 CSS） - CI 中运行命令必须是
npx html-validate "src/**/*.html" "public/**/*.html"，失败即阻断；对 SSR 模板（如index.ejs）不能扫源文件，要先构建出真实 HTML 再校验 - 常见错误现象：
ERROR: No files matching the pattern were found—— 先手动执行ls src/**/*.html确认路径是否真有匹配文件
用 Playwright 抓线上 DOM 做快照比对
静态扫描管不住 runtime 注入，比如 A/B 实验脚本、第三方 SDK 动态插入的 div 或漏掉的 aria-label，必须捕获用户真实看到的结构。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 关键动作不是截图，而是
page.content()获取完整 HTML → 用parse5重序列化（抹平格式差异）→ 清洗掉data-testid、随机id、动态class等非语义属性 → 生成哈希存档 - 比对建议放在发布后 5 分钟触发，避免 CDN 缓存未刷新导致误报；diff 差异点常暴露拼写错误被 runtime 覆盖了原始代码
- 容易踩的坑：没做标准化清洗就直接 diff —— 一个空格、换行或属性顺序不同都会触发误报，这是闭环中最容易被跳过的环节
让问题精准回流到提交者或编辑者
报警本身没用，关键是谁改的、在哪改的、怎么修。
立即学习“前端免费学习笔记（深入）”；
- 快照比对失败时，自动把异常页面 URL 和 HTML 片段写入 PR comment，并用
git blame定位到最近修改该路由模板的提交 - 对 CMS 页面，记录最后编辑人邮箱，触发钉钉/企微告警，附带修复指引链接（例如：“请检查字段映射是否漏配
alt_text”） - 禁止设置“忽略此页”的全局开关——每个例外都得走审批并写明原因，否则例外会指数级蔓延
真正难的不是搭工具链，是让每次 git push 都带着 HTML 质量承诺；而最容易被跳过的，是线上快照的「标准化清洗」。
