应选用aria-label缺失率、alt属性缺失数、嵌套深度超6层的div数量、内联样式出现频次这4个可自动采集、直指可访问性/语义化/可维护性的硬指标，配合html-validate+GitHub Actions生成每日质量快照并用轻量HTML+Chart.js可视化。
HTML代码质量该用哪些指标来量化
纯靠人工 review HTML 很难持续，必须选几个可自动采集、有明确改进方向的硬指标。重点不是“全”，而是“能驱动行动”——比如 aria-label 缺失率、alt 属性缺失数、嵌套深度超过 6 层的 div 数量、内联样式（style="..."）出现频次。这些指标背后对应着可访问性、语义化、可维护性三类真实问题，且都有成熟工具能提取。
别碰“代码行数”或“标签总数”这类无意义指标；也别一开始加 eslint-plugin-html 就开全规则——先从 3–5 个高影响项入手，否则告警太多会直接被忽略。
用 html-validate + GitHub Actions 自动生成每日质量快照
html-validate 是目前最灵活的 HTML Linter，支持自定义规则、输出 JSON 格式，适合集成进 CI 流程。在 .github/workflows/html-quality.yml 中配置它，每次 PR 或 daily cron 触发后跑一次，把结果存为 artifact 或推到专用分支。
- 关键配置项：
reporter: "json"（便于后续解析），rules: { "no-inline-style": "error", "require-alt-text": "error", "prefer-native-element": "warn" } - 注意：默认不校验远程资源（如 CDN 的 JS/CSS），若需检查，得手动加
http插件并设超时；本地开发时用html-validate --watch能实时反馈，但 CI 里禁用 - 输出的 JSON 包含每个文件的
errorCount、warningCount和具体违规位置，这是看板数据的原始来源
用轻量级静态页面做可视化看板（不用 React/Vue）
多数团队不需要 fancy 框架——一个带 fetch() 的 HTML 页面 + Chart.js 就够了。把每天生成的 JSON 报告放在 /reports/2024-06-15.json 这样的路径下，前端按日期拉取、聚合、绘图。
立即学习“前端免费学习笔记（深入）”；
示例逻辑片段：
fetch('/reports/latest.json')
.then(r => r.json())
.then(data => {
const errors = data.results.reduce((sum, file) => sum + file.errorCount, 0);
document.querySelector('#total-errors').textContent = errors;
});重点不是图表多好看，而是让任何人打开页面 3 秒内看到：今天比昨天多了 7 个 alt 缺失、某个组件的嵌套深度又破纪录了。所有图表都应带“点击钻取”能力——点某条线，跳转到对应日期的原始 JSON 文件。
指标波动时如何快速定位是真问题还是误报
质量看板一旦上线，第一周大概率会收到“这个告警没道理”的反馈。常见原因：规则配置太宽（比如把第三方 widget 的 HTML 也纳入扫描）、模板引擎生成的代码触发了语义规则（nextjs 的 Link 组件渲染成 <a> 但没 href）、或测试用的占位 HTML 没 exclude。
- 排查路径：先查
html-validate输出里的ruleId和source字段，定位到具体行；再确认该文件是否在.htmlvalidateignore中被正确排除 - 临时绕过方式：用
<!-- html-validate-disable-next-line no-inline-style -->注释，但必须带理由（例如// legacy banner widget, will refactor in Q3） - 真正要改的是规则阈值——比如把嵌套深度警告从 >6 改为 >8，只在连续 3 天超标时才标红，避免噪声干扰
真正难的不是建看板，而是让每个新提交的 HTML 都带着上下文：为什么这里不用 button 而用 div role="button"？那个 alt="" 真的是装饰性图片吗？这些判断没法自动化，得靠看板旁附上“规则说明链接”和“修改示例”，不然数字再准也没用。
