HTML质量缺陷不能靠肉眼或格式校验发现，因其属语义级问题：如data-testid写错、aria-label缺失、内联样式覆盖响应式、src资源404无onerror回退等，需Playwright在真实浏览器中结合DOM状态与自定义断言拦截。
HTML质量缺陷为什么不能靠肉眼或格式校验发现
HTML本身是静态标记，npm run build 生成的 dist/index.html 即使语法合法，也可能埋着严重缺陷：比如 data-testid 属性写错导致自动化脚本定位失败、aria-label 缺失让无障碍测试挂掉、内联样式覆盖了响应式断点、或者 src 指向不存在的图片资源却没配 onerror 回退逻辑。这些都不是 W3C 验证器能报出来的，也不是 ESLint 能扫到的——它们属于“语义级质量缺陷”，必须结合运行时行为和上下文规则来判断。
用 Playwright + 自定义断言拦截 HTML 缺陷
真正起作用的不是 HTML 文件本身，而是它在浏览器中加载后暴露的 DOM 状态。Playwright 是目前最稳妥的选择，因为它启动真实 Chromium 实例，能准确复现用户视角下的渲染结果。
- 检查关键元素是否存在且可交互：
await expect(page.locator('header nav a[href="/projects"]')).toBeVisible() - 验证 ARIA 属性合规性：
await expect(page.locator('[role="navigation"]')).toHaveAttribute('aria-label', 'Main navigation') - 捕获资源加载失败：
page.on('response', r => { if (r.status() === 404 && r.url().endsWith('.png')) throw new Error(`Missing image: ${r.url()}`) }) - 检测未闭合标签引发的 DOM 结构偏移（常见于模板拼接错误）：
await expect(page.locator('main > article')).toHaveCount(3)，而不是依赖 class 名硬匹配
CI 流程中 HTML 质量检查的嵌入时机
别把 HTML 质量检查塞进构建后阶段——那时缺陷已经固化进 dist/。应该在构建过程中就注入验证环节：
- Parcel 或 Vite 构建完成后，自动执行
npx playwright test --project=html-quality，该配置专跑 HTML 结构与语义断言 - GitHub Actions 中，
.github/workflows/ci.yml的buildjob 后必须紧跟html-checkjob，且设置needs: build强制顺序 - 失败时不只报
Test failed，要提取具体缺失的alt文本或无效href值，直接输出到 PR comment 里，避免开发者来回翻日志 - 注意缓存干扰：Playwright 默认启用浏览器缓存，需显式加
page.goto(url, { waitUntil: 'networkidle' })，否则 404 资源可能被缓存掩盖
容易被忽略的 HTML 运行时缺陷类型
很多团队只查静态结构，却漏掉三类高频问题：
立即学习“前端免费学习笔记（深入）”；
-
IntersectionObserver监听失效：滚动到底部时“加载更多”按钮没触发，根本原因是 HTML 中对应容器缺少id或初始display: none导致 observer 无法注册 - 动态
data-属性更新不同步：JS 修改了data-status，但 aria-live 区域没同步更新，屏幕阅读器读不到状态变化——这需要在 Playwright 中用page.evaluate主动读取 DOM 属性比对 - 第三方脚本注入污染：如统计代码往
<body>插入无意义div，破坏 CSS 选择器稳定性，必须在测试前用page.addInitScript清理非预期节点
HTML 质量缺陷的隐蔽性在于它不报错、不崩溃，只悄悄降低可访问性、SEO 权重或自动化脚本稳定性。真正有效的拦截，得在浏览器里看它“活起来”之后再动手。
