大厂团队用规则引擎和统计指标量化HTML质量，聚焦aria-*缺失、非法嵌套、重复id等硬性缺陷；不用ESLint因它仅处理JS AST，需html-validate或AST分析层；通过PR扫描、页面聚合、OKR绑定驱动改进闭环。
大厂团队不靠“肉眼评审”或“主观打分”判断 HTML 质量，而是把 HTML 当作可测量的工程产出——用规则引擎 + 统计指标驱动改进闭环。
怎么定义“质量差”的 HTML？先锁定三类硬性缺陷
不是所有“不优雅”的写法都算问题。真正被量化模型盯上的，是直接影响可访问性、渲染性能、维护成本的硬伤：
-
aria-*属性缺失或误用（如aria-hidden="true"加在焦点元素上） - 嵌套非法或语义断裂（如
<div> 直接包 <code><h1></h1>但无section上下文） - 重复
id、缺失alt、img无宽高属性导致 CLS 偏高 -
required属性只对input、select、textarea有效，对div加它毫无意义，但静态检查容易漏判上下文 -
role="button"必须配合tabindex和键盘事件监听，单看 HTML 标签无法确认是否真可交互 - 某些框架生成的 HTML（如 React 的
data-reactroot）属于合法噪声，需白名单过滤，否则指标失真 - 每个 PR 自动运行
html-validate --output-format=json，提取errorCount、warningCount、ruleViolations字段存入 CI 日志 - 按页面 URL 聚合（如
/user/profile页面近 30 天missing-alt从 12 降到 0），而非只看全局总数 - 把高频违规规则（如
no-inline-style）和组件库版本号关联，发现某次升级后该问题激增，立刻回溯 PR -
v-html内容完全逃逸校验，但实际可能含未闭合标签 - 服务端返回的 HTML 包含占位符（如
{{title}}），被解析成无效节点 - 构建时
html-webpack-plugin注入的script标签顺序影响defer生效逻辑，但扫描器只看最终字符串
这些不是风格争议，是浏览器/辅助技术明确报错或触发性能惩罚的点，能被 axe-core、html-validate 或自研 AST 解析器稳定捕获。
为什么不用 ESLint 那套规则直接套 HTML？
ESLint 处理的是 JS AST，而 HTML 的语义约束和 DOM 运行时行为强相关。比如：
立即学习“前端免费学习笔记（深入）”；
所以大厂普遍用 html-validate + 自定义插件，或基于 parse5 构建轻量 AST 分析层，把校验逻辑绑定到具体标签生命周期阶段。
如何把检查结果变成可追踪的团队指标？
单次扫描报告没用，关键在于把问题映射到人、提交、页面路径，并形成趋势曲线：
指标本身不驱动改进，但当 accessibility-score 被纳入组件负责人季度 OKR，且每天推送“你负责的 3 个页面新增了 2 条 aria-invalid 误用”，事情就变了。
最容易被忽略的陷阱：HTML 质量指标会“假阳性”膨胀
模板引擎注入、SSR 渲染差异、动态 innerHTML 拼接，会让静态扫描结果严重偏离真实 DOM 结构。比如：
真正可靠的评估，必须在真实环境（DevTools 的 Elements 面板或 Puppeteer 截取渲染后 DOM）做二次验证，而不是只信构建产物扫描结果。
