html质量需嵌入全流程：提交时用html-validate拦截结构/可访问性错误，ci中用puppeteer+axe-core做运行时无障碍快照比对，storybook+playwright实现组件视觉回归，lighthouse ci监控预发环境语义与性能退化。
HTML 代码质量在跨职能敏捷团队里，不能靠“人眼扫一遍”或“上线前手动点几下”来兜底。它必须嵌入到开发、测试、交付的每个环节，且能被前端、后端、QA 共同理解、触发和响应。关键不是堆工具，而是让 HTML 的语义、结构、可访问性、渲染一致性，在提交、构建、预发阶段自动暴露问题。
本地提交时用 html-validate 拦住基础结构错误
很多团队只在 CI 里做 HTML 检查，结果等 PR 提交后才发现 <div> 嵌套了 <code><p></p>、aria-label 缺失、或者 id 重复 —— 这类问题本该在保存文件时就提示。用 html-validate 配合 Husky + lint-staged，能在 git commit 前拦截。
- 默认规则太宽松，建议基于
a11y（无障碍）和recommended启动，再按项目加no-inline-style、no-duplicate-id等硬性项 - 不要只校验
.html文件：Vue/React 组件里的模板片段（如.vue中的<template></template>）需通过插件html-validate-vue或自定义 parser 支持 - 常见报错如
"Element 'img' must have an 'alt' attribute"，不是警告，是直接中断commit—— 别设成warn，否则等于没拦
CI 流水线中用 Puppeteer + axe-core 做可访问性快照比对
单纯静态校验无法发现运行时问题：比如 JS 动态插入的 DOM 缺少 role，或者 SSR 渲染与 CSR 混合后语义丢失。axe-core 必须在真实浏览器环境执行，而 Puppeteer 是最轻量可控的选择。
- 不要只跑一次
axe.run()：对关键路由（如首页、登录页、商品详情页）分别启动页面，逐个采集axe结果并生成 JSON 报告 - 把历史报告存为 baseline，每次 CI 对比新增
violations数量 —— 如果比上一版多出 2 条以上critical级别问题，就标为失败 - 避免误报：某些框架自动生成的
data-*属性会被误判为无效属性，需在axe.configure()中显式忽略allowedOrigins或自定义rules
组件库级用 Storybook + playwright 自动化视觉回归
跨职能团队里，UI 工程师、设计师、前端都依赖组件库。但一个 margin 的微调、一次 CSS 变量升级，可能让所有引用它的页面布局错乱。靠人工点开 Storybook 检查 50+ 组件不现实。
-
playwright截图必须开启deviceScaleFactor: 1和固定 viewport（如1280x720），否则不同机器渲染像素偏移会导致误判 - 不要只比对整页截图：对每个 story 提取关键区域（如按钮的 hover 态、表单输入框的 focus 框）做局部比对，提升准确率
- 把
storybook的docstab 也纳入扫描范围 —— 很多团队文档里的示例代码是手写的，和实际组件行为不一致，这里容易埋坑
合并后用 Lighthouse CI 监控核心页面性能与语义退化
PR 合并后，没人再盯着 HTML。但真实环境里，新引入的第三方脚本可能篡改 ，服务端模板引擎升级可能漏掉 lang 属性，这些都会在夜间批量发生。
-
Lighthouse CI要配置collect.url指向预发环境的真实 URL（不是本地localhost），否则测不到 CDN、HTTP 头、服务端渲染真实链路 - 重点监控三项：
accessibility分数波动（±3 分以上告警）、best-practices中document.write或内联样式出现、seo里viewport或lang缺失 - 把
lighthouse报告存档，并和git blame关联 —— 当某次发布后accessibility分从 98 降到 82，能立刻定位到是谁改了哪个 layout 组件
最难的不是搭完这套流程，而是让 QA 能看懂 axe 报告里的 color-contrast 问题为什么算 blocker，让产品能理解为什么 aria-live 缺失会影响屏幕阅读器用户下单路径。自动化跑测的价值，不在“跑”，而在“谁都能快速读懂它在说什么”。
