HTML代码质量验收必须由CI/CD流水线卡口，前端配置htmlhint/axe规则，DevOps集成校验，产品/设计参与制定可验证的语义checklist（如“所有图片有非空alt”“导航必须用nav包裹”），工具自动拦截技术问题，人工聚焦内容意图匹配。
HTML代码质量验收该由谁来卡口
不是前端一个人说了算，也不是测试或产品拍板决定。真正有效的卡口必须落在CI/CD流水线里，且触发条件明确——htmlhint报错、axe-core可访问性得分低于85、prettier格式校验失败，任意一项未通过，PR就无法合并。
常见错误是把“代码评审”等同于“人工看一眼”。实际中，非前端成员（如产品经理、UI设计师）只需关注语义标签是否匹配内容意图（比如新闻列表用了article还是div），而技术细节（嵌套合法性、ARIA属性缺失）应由工具自动拦截。
- 前端工程师负责配置和维护
.htmlhintrc与axe规则集，确保覆盖团队约定的语义化底线（如h1唯一、button不可替换成div onclick） - DevOps需在CI脚本中加入
npx htmlhint src/**/*.html和npx axe-cli --ci --reporter=json，失败直接中断构建 - 产品/设计人员参与制定验收checklist：例如“所有图片必须有
alt且非空字符串”“导航区域必须包裹在nav内”，这条写进PR模板，作为协作确认项
如何让非技术人员也能理解HTML质量标准
把抽象规范转成可验证的陈述句，避免术语堆砌。比如不说“遵循语义化原则”，而说：“标题层级从h1开始，逐级递进，不能跳过h2直接用h4；商品价格必须放在span里并加itemprop="price"。”
这类句子可以直接塞进PR描述模板，每次提交时自动带出。非技术人员只需对照页面截图和这几句检查，勾选即可，不用打开源码。
立即学习“前端免费学习笔记（深入）”；
- 用真实HTML片段做对比示例：左边是错误写法
<div class="btn">提交</div>，右边是正确写法<button type="submit">提交</button>，附带一句话说明“屏幕阅读器能识别button，但读不懂div的点击意图” - 给设计稿标注语义锚点：Figma文件里用注释标出“此处对应
aside区块”“筛选栏需用form包裹”，同步到开发任务卡 - 拒绝“差不多就行”：比如
img的alt值为空字符串alt=""和缺失alt属性，在htmlhint里是不同错误类型，必须区分处理
跨团队协作时HTML验收最容易被绕过的环节
不是格式混乱，也不是标签用错，而是**元信息缺失且无校验机制**。比如meta charset写错、viewport没设、title动态渲染后为空——这些不会导致页面白屏，但会引发SEO失效、移动端缩放异常、爬虫抓取失败等隐蔽问题。
这类问题常被忽略，因为本地开发时一切正常，上线后才暴露。根本原因是：它们不在视觉验收范围内，也不在功能测试用例里。
- 在CI中单独跑
grep -q "charset=utf-8" *.html这类轻量检查，比解析DOM更可靠 - 用Puppeteer启动真实浏览器，执行
document.title和document.querySelector('meta[name="viewport"]')断言，捕获JS渲染后的最终状态 - 把
title长度、description字符数、canonical链接有效性做成独立监控项，接入告警系统，而非仅依赖人工抽检
为什么团队共用同一套.prettierrc还不够
因为prettier只管“怎么写好看”，不管“写得对不对”。它能把<div class="card"><h3>标题</h3><p>内容</p></div>格式化得整整齐齐，但无法指出这里该用article而不是div。
真正的标准化接收机制，必须是多层过滤：prettier → htmlhint → axe → 自定义XPath校验。每一层解决一类问题，漏掉任何一层，都会让质量防线出现缺口。
-
prettier统一换行、缩进、引号，降低diff噪声 -
htmlhint盯结构：强制img必须有alt、禁止table用于布局、限制嵌套深度 -
axe-core查可访问性：颜色对比度、焦点顺序、ARIA role合法性 - 自定义脚本验证业务规则：比如所有
data-testid属性必须以test-开头，否则E2E测试无法定位
htmlhint规则更新，也没人定期清理过时的XPath断言。一旦某个环节长期无人看管，整条验收流水线就会退化成摆设。 
