HTML本身不能被测试，只能被解析、校验或驱动；HTMLProofer是最轻量的纯HTML质量监控方案，适用于静态站点和CI兜底，仅验证资源可达性与结构合法性。
HTML 本身不能被“测试”，只能被解析、校验、驱动——自动化监控的入口点永远是 JavaScript 运行时或外部 CLI 工具，不是 <html> 标签。
用 HTMLProofer 检查链接、图片和脚本有效性
这是最轻量、最贴近“纯 HTML 质量监控”的方案，适合静态站点或 CI 中快速兜底。它不依赖浏览器，只做资源可达性与结构合法性验证。
- 常见错误现象：
404链接未被发现、<img src="missing.png">导致页面留白但无报错、<script src="bundle.js">返回403却仍被当作成功加载 - 使用场景：Jekyll/Hugo/Gatsby 构建后产物检查、PR 合并前的准入卡点
- 参数差异：
--url-ignore "/admin/,/api/"可跳过动态路径；--check-favicon默认关闭，需显式启用；--http-status-ignore 0能容忍本地文件协议下的状态码缺失 - 性能影响：对千页级站点，默认并发数
25可能触发目标服务器限流，建议设为--concurrency 5并加--timeout 10
用 Puppeteer + 自定义规则做 DOM 层语义与结构校验
当你要验证的是“人眼可见的 HTML 质量”——比如 <h1> 是否唯一、alt 是否缺失、aria-label 是否冗余——就必须启动真实浏览器环境执行检查逻辑。
- 常见错误现象：
document.querySelectorAll('h1').length !== 1却没人发现；img[alt=""]被误认为已填写；role="button"元素没绑定click事件 - 使用场景：企业官网发布前巡检、SEO 审计脚本、无障碍合规初筛
- 关键注意点：必须等
page.waitForSelector('body')或page.waitForLoadState('networkidle')，否则$$('img')可能返回空数组；避免直接用evaluate()执行复杂逻辑，应拆成小函数注入 - 兼容性影响：Puppeteer 默认用 Chromium，若需 Safari 行为验证，得换用 Playwright 并指定
webkitchannel
用 Cheerio + ESLint 插件做静态结构合规检查
适用于构建阶段介入，在 HTML 文件落地磁盘后、部署前扫描其语法结构与属性规范性，速度极快，但无法感知运行时行为。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：
<div class="header">实际该用<header>；<a href="#" onclick="goHome()">缺少role="button"；<input type="email">没配required却标称必填 - 使用场景：Git Hook 触发的 pre-commit 检查、CI 中对
src/templates/下原始模板的 lint - 配置项注意：
cheerio-linter不支持自定义规则，推荐用eslint-plugin-html+eslint-plugin-jsx-a11y组合；rules: { 'jsx-a11y/anchor-is-valid': ['error', { aspects: ['noHref'] }] }可精准控制校验粒度 - 容易踩的坑：Cheerio 默认不解析
<template>内容，若模板含服务端 include，需先预处理展开；对内联<script>中的字符串插值（如data-id="${id}"）会误报属性非法
W3C Validator API 不适合集成到自动化流水线
虽然它是权威标准，但它的 API 响应慢、限频严、错误定位模糊（只给行号，不给 selector），且不支持批量提交或自定义规则忽略。
- 典型失败表现：
HTTP 429 Too Many Requests在并发扫描 20+ 页面时必然触发；"The document is not mappable to XML"错误常因内联 SVG 或 Web Component 的自定义标签导致，实际不影响渲染 - 替代方案：本地部署
nu-validatorDocker 镜像，用curl -X POST --data-binary @file.html http://localhost:8888调用，响应时间从秒级降到毫秒级 - 真正要监控的不是“是否符合 W3C”，而是“是否破坏核心功能”——比如
<form>缺method导致提交变成 GET；<button>在表单内没设type触发意外提交。这些必须靠业务规则断言，不是靠 DTD 校验
最容易被忽略的一点：所有 HTML 质量监控都建立在“页面可被稳定获取”前提上。如果 fetch() 或 goto() 失败率超过 5%，后续所有校验都是噪声。务必先加一层健康检查——比如用 curl -I 验证 HTTP 状态码和 Content-Type: text/html，再决定是否进入深度分析流程。
