W3C验证必须纳入CI流水线，因为浏览器静默修复与服务端解析逻辑不一致，导致Chrome/Safari DOM结构差异、React hydration mismatch及CI中querySelector随机失效；离线工具html-validate配合parse5可实现快速、可靠、可中断构建的合法性校验。
HTML模板合法性不是“测不测”的问题，而是“不验就上线等于裸奔”——W3C验证失败的页面，浏览器会静默修复结构，但修复逻辑各厂商不一致，导致DOM树在Chrome和Safari中实际形态不同，document.querySelector在CI环境里随机失效。
为什么W3C验证结果必须进CI流水线
本地能跑通的HTML，在CI里可能解析失败或结构错乱，根本原因是：浏览器容错 ≠ 构建环境容错。Node.js里的parse5、JSDOM或服务端渲染引擎（如Next.js SSR）不会模拟浏览器的纠错行为，遇到未闭合<div>或非法嵌套<code><p></p>
<div></div>直接抛错或生成意外DOM。
- W3C验证器报错项（如“End tag
<div> seen, but there were open elements”）对应真实运行时异常：React hydration mismatch、Vue SSR水合失败 <li>警告项（如“<code><img>missingalt”）虽不阻断渲染，但触发Lighthouse可访问性评分归零，影响SEO与合规审计 - 用
file://协议校验会漏掉Content-Type相关错误，CI中必须走http://localhost:8000或page.setContent(htmlString)方式加载 - 禁用
attr-bans等宽松规则，强制启用require-lang-attribute、valid-href、no-inline-style - 对
<template></template>标签内容跳过校验——它本就不参与主DOM解析，W3C也忽略，不必额外配置 - 内联
<script></script>或<style></style>里含或<code>&时，校验器会截断报错，这不是HTML问题，是字符未转义，需前置过滤 - CI脚本示例：
npx html-validate --config .htmlvalidate.json src/**/*.html，退出码非0即中断构建 - 检查HTML文件第一行是否为
，且前面不能有任何空格、BOM或注释 - SSR框架（如Nuxt 3）默认不保留
data-test-id，需显式配置ssr-identifiers或改用data-testid（更通用） - 别为了过W3C而删
data-test-id——它对测试稳定性至关重要；应修复doctype，而不是妥协定位策略
怎么把W3C验证塞进CI而不拖慢构建
调W3C API有速率限制且依赖网络，真正在CI里落地得用离线方案。推荐组合：parse5 + html-validate，规则集聚焦硬性标准。
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
data-test-id加了，W3C却报“unknown attribute”怎么办
data-test-id是合法的自定义属性，W3C报这个错只有一种可能：你没写。没有doctype，文档进入Quirks Mode，解析器按旧标准处理，所有<code>data-前缀属性都被视为非法。
最常被忽略的一点：W3C验证通过，只代表语法合法；但data-test-id写在父容器上、里面多个子元素共享同一值，这种“合法但不可用”的HTML，照样让Playwright脚本随机失败。
