HTML代码质量需三重自动化监控：静态用HTMLHint做CI/CD检查，运行时用Puppeteer+cheerio校验真实DOM，合规性用封装W3C验证器；统一问题定义比工具堆砌更重要。
线上HTML代码质量缺陷不会自己报错，但会悄悄导致SEO掉权、无障碍访问失败、爬虫抓取中断或JS选择器失效——必须靠自动化监控主动拦截，而不是等用户投诉才去翻日志。
用 HTMLHint 做 CI/CD 阶段的静态检查
这是最轻量、最可控的第一道防线。HTMLHint 不依赖浏览器环境，纯文本扫描，适合在代码提交或 PR 时快速反馈问题。
- 在项目根目录运行
npx htmlhint --init生成默认.htmlhintrc，再按需开启关键规则：比如"tag-pair": true（强制闭合）、"id-unique": true（防重复ID）、"alt-require": true（图片必须带alt） - GitHub Actions 中避免写
npx htmlhint "**/*.html"这种宽泛路径——它会扫 node_modules 和构建产物，拖慢流水线；改用npx htmlhint src/**/*.html public/*.html - CI 中遇到
ERROR: No files matching the pattern were found，大概率是 glob 路径没匹配到任何 HTML 文件，先手动执行ls src/**/*.html确认路径有效性 - 别把 HTMLHint 当“万能校验器”：它不检测 DOM 渲染后动态插入的内容，也不验证
data-testid是否真被 JS 读取——那是 Playwright 的事
用 Puppeteer + 自定义脚本做上线后运行时校验
静态检查管不到服务端渲染（SSR）或客户端水合（hydration）后的实际 HTML 结构，这时得让真实浏览器跑一遍。
- 核心逻辑不是“截图”，而是
page.content()拿到最终 DOM 字符串，再用cheerio.load()解析校验：比如检查h1是否存在、title长度是否在 30–60 字符之间、所有img的src是否返回 200 - 注意超时设置：
page.goto(url, { timeout: 15000 })，否则首屏 JS 加载慢会导致校验直接跳过 - 若页面含登录态或地域限制，需提前注入
cookies或用page.authenticate()，否则拿到的是 403 页面源码，校验全失效 - 别在无头模式下忽略视口设置：
page.setViewport({ width: 1920, height: 1080 })，否则媒体查询可能不触发，导致meta name="viewport"校验误报
把 W3C 验证器集成进告警链路，而非只当手动工具
W3C Validator 是黄金标准，但它官方 API 不稳定、响应慢，不能裸用。得加一层封装和兜底。
立即学习“前端免费学习笔记（深入）”；
- 不要直连
https://validator.w3.org/nu/：它有请求频率限制，且返回 JSON 结构复杂；推荐用社区维护的轻量封装库如w3c-validator-cli，支持本地缓存与重试 - 校验前先做预处理：移除注释、压缩空格、过滤非标准属性（如
v-html），否则大量“非错误警告”会淹没真实问题 - 把校验结果映射成可告警指标：比如“严重错误数 > 0”触发钉钉通知，“警告数周环比 +30%”标记为潜在重构信号
- 遇到
429 Too Many Requests错误，不是加大并发，而是加sleep(1000)限流，并记录失败 URL 到待重试队列
真正难的不是跑通某一个工具，而是让三类检查（静态 / 运行时 / 标准合规）的结果能对齐同一套问题定义——比如“缺少 alt 属性”在 HTMLHint 里是 warning，在 Puppeteer 脚本里是 error，在 W3C 报告里可能根本不提。统一问题 ID 和分级口径，比堆工具重要得多。
