cheerio与nu-validator必须配合使用：cheerio提取语义标签结构并检查嵌套关系，nu-validator验证W3C标准合规性，二者结合才能发现嵌套错误、闭合遗漏及隐性语义问题。
如何用 cheerio + nu-validator 检查语义标签缺失
大型官网常见问题不是“没写 <header>”，而是“写了但嵌套错、漏闭合、混用 <div> 替代语义标签”。cheerio 能快速提取 DOM 结构，但只做静态解析；nu-validator 才能验证是否符合 W3C 标准。二者必须配合使用，否则会漏掉 <main> 里嵌套 <article> 却没加 role="article" 这类隐性问题。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 先用
cheerio.load(html)提取所有<section>、<aside>、<nav>，检查父级是否为<main>或<body>，避免直接挂在<div>下 - 对每个语义标签调用
nu.validator的 POST 接口，传入片段 HTML（不是整页），避免因外部资源加载失败导致校验中断 - 特别注意
<h1>到<h6>的层级跳跃——<h3>后直接跟<h1>会被 nu-validator 报Heading level skip
为什么 puppeteer 必须用于检测动态渲染的移动端适配
纯静态 HTML 扫描无法发现媒体查询失效、@media (max-width: 768px) 写了但未生效、或 CSS-in-JS 注入后覆盖了响应式规则等问题。puppeteer 能真实模拟 Chrome 在不同 viewport 下的渲染结果，并提取 computed styles 和 layout 块尺寸。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 启动 puppeteer 时指定
defaultViewport: { width: 375, height: 667 }，再执行page.emulateMediaType('screen')，避免被服务端识别为 bot 返回降级页面 - 检查触控目标（touch target）是否 ≥ 44px：用
page.$$eval('a, button, [role="button"]', els => els.map(el => el.getBoundingClientRect().height)) - 不要只测一个断点——需覆盖
320px、375px、768px、1024px四个典型宽度，否则会漏掉平板横屏下导航栏错位这类问题
历史对比报告中哪些数据容易被误读
直接比对两次扫描的“错误总数”毫无意义。比如某次修复了 50 个 alt 缺失，但新增了 30 个第三方组件注入的无效 <iframe>，总错误数反而下降，实际质量在退化。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只对核心指标做趋势对比：
semantic_tag_compliance_rate（语义标签合规率）、seo_meta_coverage（title/description/h1 覆盖率）、mobile_touch_target_pass_rate - 把第三方脚本生成的 DOM 片段加入白名单，但要求其提供可验证的
data-source属性，例如<div data-source="livechat-v2.1">，否则不计入统计 - 每次扫描前强制清除浏览器缓存并禁用所有扩展，否则 Puppeteer 可能复用旧样式表导致媒体查询检测失真
Git 钩子触发检查时怎么避免阻塞提交
全站 HTML 扫描耗时 2–8 分钟，不可能放在 pre-commit 阶段。强行阻塞会导致开发者绕过钩子或本地调试失败。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- pre-commit 只运行轻量级检查：
grep -q '<doctype' $file、grep -q 'lang=' $file、grep -E 'meta.*name="viewport"' $file - 真正扫描放在 pre-push 阶段，且仅检查本次提交涉及的 HTML 文件路径（通过
git diff --name-only @{u} HEAD -- '*.html'获取） - 扫描结果不阻断推送，而是自动提交到专用分支
quality-report/$(git rev-parse --short HEAD)，供 CI 流水线后续拉取生成可视化报告
真正难的不是发现 <div class="header">，而是判断它该不该改成 <header>——这取决于它在 DOM 树里的上下文、是否被屏幕阅读器聚焦、有没有参与大纲算法。自动化工具只能标出嫌疑点，最终决策必须由前端架构师结合业务逻辑拍板。
