应在CI流程中嵌入html-validate静态检查，仅校验Git diff涉及的HTML文件，强制校验alt属性、禁止无role的div模拟交互，并配置语义审查员作为必选评审人。
如何在 feature 分支里提前拦截语义错误
HTML 语义错误（比如用 <div> 冒充 <button>、缺失 alt、<main> 缺失或重复）不会触发构建失败，但会悄悄污染主干。CI 流程里必须嵌入轻量级 HTML 静态检查，而不是等上线后靠人工 Review。
- 用
html-validate配合自定义规则（如强制<img>必须含alt、禁止无role的<div>模拟交互控件） - 把检查命令加进
package.json的test:html脚本，并在 PR 触发的 CI 中运行 - 避免全量扫描：只校验本次变更涉及的 HTML 文件（Git diff 提取路径传给
html-validate） - 不依赖 IDE 插件——它只在本地生效，而真正要守住的是合并前那道门
为什么 pre-commit 钩子对 HTML 质量作用有限
pre-commit 能拦住明显语法错误，但对结构性缺陷（比如语义层级错乱、ARIA 属性缺失、可访问性逻辑断裂）几乎无效。它运行在单文件上下文，看不到组件组合后的 DOM 结构，也读不到跨文件引用的模板片段。
- 例如：一个
<header>在 A.html，<nav>在 B.html，两者拼在一起才构成完整语义——pre-commit看不到这个关系 - 它无法检测服务端渲染后生成的 HTML（如 Next.js 的
getServerSideProps输出），因为那些内容不在 Git 工作区里 - 真正有效的检查必须发生在构建产物阶段，或至少是整合所有模板后的静态 HTML 输出目录
- 如果硬要用
pre-commit，只建议做基础格式校验（缩进、闭合标签），别指望它守质量底线
PR Review 时怎么快速验证 HTML 回退风险
Review 不是扫代码，而是盯「变化引入了什么新结构」。重点不是看写了什么，而是看删了什么、改了什么语义边界。
- 对比前后 HTML diff：重点关注
<section>、<article>、<aside>等语义容器的增减，以及role、aria-*属性的变动 - 检查是否新增了内联
style或!important——它们常是绕过 CSS 架构的信号，后续容易引发样式不可维护 - 确认所有新图片都带
alt，且值非空字符串或占位符（如"image"）；视频/音频元素是否提供<track>或文字摘要 - 用浏览器的 Lighthouse（Accessibility Audit）跑一次变更页——不是看总分，而是看新增的「fails」条目是否与本次修改直接相关
主干保护策略里漏掉的关键一环
很多团队设了 required_pull_request_reviews 和 CI 通过才允许合并，但没限制「谁有权限批准 HTML 相关变更」。一个没接触过无障碍标准的开发者点 approve，等于给语义退化开了绿灯。
立即学习“前端免费学习笔记（深入）”；
- 在 GitHub/GitLab 的 branch protection 规则中，应配置
required_reviewers组，指定至少一名熟悉 WCAG 和 HTML5 语义的成员 - 把 HTML 质量卡点写进团队 Wiki 的 PR 检查清单（Checklist），并和 CI 报告联动：比如
html-validate错误数 > 0 时，自动在 PR 评论里贴出具体行号和规则链接 - 最易被忽略的是「回滚场景」：当某次 hotfix 紧急修复跳过了常规 Review，事后必须补上 HTML 合规性审计，否则技术债会像雪球一样越滚越大
