很多团队在开展HTML结构检查时,仍依赖正则表达式匹配 、,但一旦遇到嵌套标签或属性拼写错误,正则往往无声无息地遗漏问题。真正稳定可靠的方案,是借助 cheerio 像 jQuery 那样操作 DOM,并且完全无需浏览器环境。不过,这里有一个关键前提:W3C 的 nu-validator 是业内经过广泛验证的合规性检查服务,然而它的 API 返回的是 JSON 而非 HTML——你必须解析 messages 数组中的 message、line、extract 字段才能精准定位问题,不能把它当作黑盒随意调用。

用 cheerio + W3C nu-validator 实现 HTML 结构检查
以下几条实战经验值得牢记:
- 调用 validator 时,务必检查返回的
status是否为0,否则可能拿到空结果或超时错误,白白浪费一次请求。 cheerio.load(html, { xmlMode: false, decodeEntities: true })中的xmlMode: false必须显式声明,否则里带<的代码会被误判为非法标签,导致整个解析出错。- 第三方组件(例如 Vue SSR 输出)经常生成
这类属性,默认会被 validator 报错。解决办法是在请求体中添加{"showsource": false},并配合白名单过滤掉这些无关警告。
生成可交互的 HTML 看板页面,而非静态表格
如果仅靠 template 拼接字符串生成报告,后期维护成本高、样式难以统一,而且修改起来令人头疼。真正实用的看板,应该支持点击问题跳转到源码行号、按严重等级筛选、对比历史分数趋势——这些功能通过静态表格无法实现。
推荐的做法是后端只提供 JSON 数据接口(例如 /api/report/latest),前端用 ECharts 做纯渲染,这样每次更新报告时无需写磁盘文件,灵活性更高。
- 表格列不要硬编码字段名,比如“触控目标尺寸”这类描述性文字,应映射为
touch_target_size这样的键名,方便前端进行条件渲染和排序。 缺失和缺少alt的严重程度完全不同,报告里必须区分error/warning/info三类,不能全部塞进一个中。 - 样式文件不要内联在 HTML 里,用
单独引用,否则 nginx 缓存失效时样式错乱,排查起来非常麻烦。用 SQLite 存储历史数据,但需留意时间精度陷阱
SQLite 确实轻量,但默认的
DATETIME类型不带毫秒——一次扫描可能耗时 850ms,如果两轮检查间隔小于 1 秒,后一条记录会直接覆盖前一条。这个坑很多人踩过。解决方案很简单:建表时使用
TEXT存储 ISO8601 格式时间(例如"2026-06-30T14:22:18.427Z"),查询时用strftime('%Y-%m-%d %H:%M', timestamp)做小时级聚合,既能保证精度,又方便统计。- 不要直接使用
datetime.now()插入——Python 的datetime对象转字符串时默认不带毫秒,必须显式调用.isoformat()。 - 历史对比图如果只取最近 7 条,但某天跑了 3 次扫描,就会漏掉中间那次。正确做法是按日期分组取
MAX(timestamp),而不是简单的 LIMIT 7。 - SQLite 不支持
JSON_EXTRACT,所以检查项明细(例如每个页面的img_without_alt列表)建议序列化为 JSON 字符串,存入details TEXT字段,前端再解析。
接入 CI/CD 时避开 Puppeteer 渲染陷阱
如果官网使用了 React 或 Vue,静态爬虫抓到的只是空
,必须通过 Puppeteer 预渲染。但默认配置下,Puppeteer 启动慢、内存泄漏明显,CI 环境尤其容易失败。核心调整项实际上只有三个:
headless: "new"(启用新版无头模式)、args: ["--no-sandbox", "--disable-setuid-sandbox"](Docker 容器必需)、timeout: 15000(避免单页卡死拖垮整批任务)。- 不要在每次检查时都 new Browser()——复用同一个实例,用
browser.newPage()打开新页面,否则 20 个页面会启动 20 个 Chromium 进程,资源瞬间耗尽。 - 动态内容检测完成后立即调用
page.close(),否则内存持续上涨,CI 机器跑几轮就会 OOM。 - 移动端适配检查不能只靠
page.emulateMediaFeatures([{name: "prefers-color-scheme", value: "dark"}]),必须真实触发window.innerWidth变化,并等待document.readyState === "complete"才能确保渲染无误。
另外,实际部署时最容易被忽略的是
robots.txt对爬虫路径的限制——自动化检查脚本默认会遵守它,但企业官网往往把测试页或 CMS 后台路径写进了 Disallow,导致漏检。上线前务必确认检查服务的 User-Agent 不在屏蔽列表中,或者临时绕过 robots 协议,否则辛辛苦苦搭建的看板可能只检查了首页。- 样式文件不要内联在 HTML 里,用
