建立在团队敏捷Code Review中的前端HTML代码质量审查细则-html教程-PHP中文网

HTML是可访问性、SEO、性能和协作的第一道防线，必须语义化、可读可维护；需正确使用标签、a11y属性、预加载、尺寸声明及团队规范。

建立在团队敏捷code review中的前端html代码质量审查细则

前端 HTML 代码在 Code Review 中最容易被轻视，但恰恰是可访问性、SEO、渲染性能和团队协作一致性的第一道防线。它不是“写完能跑就行”，而是必须可读、可维护、可测试、可访问。

HTML 结构是否符合语义化规范？

语义化不是为了“看起来高级”，而是让浏览器、屏幕阅读器、搜索引擎和后续维护者能准确理解内容意图。常见误用：

 套  模拟按钮或标题， 替代 ， 滥用而忽略  或  的实际含义。按钮交互必须用 （带原生 focus、空格/回车触发、type="button" 防提交），禁用  或 
标题层级必须严格递进：从  开始，禁止跳级（如  后直接 ）

列表内容必须用 /，禁止用  + CSS 模拟
表单控件必须包裹在  内，且每个  必须有对应 （for 属性或嵌套）

是否遗漏关键可访问性（a11y）属性？
很多 HTML 问题在视觉上完全正常，却导致屏幕阅读器无法朗读、键盘导航中断、自动化 a11y 工具报错。这不是“锦上添花”，而是合规底线。

所有图片必须有 alt 属性：有意义的图写描述，纯装饰图写 alt=""（空字符串，不是省略）
自定义弹窗/下拉菜单必须有 role（如 role="dialog"）、aria-modal="true"、aria-labelledby，且需管理焦点流
动态更新区域（如搜索建议、状态提示）需加 aria-live="polite" 或 "assertive"

禁用 tabindex="0" 在非交互元素上——除非你已实现完整键盘操作逻辑（包括 Enter/Space、方向键、Escape）

是否存在影响渲染性能或 SEO 的硬编码问题？
HTML 是页面首次渲染的起点，某些写法会直接拖慢首屏、破坏预加载、干扰爬虫解析。

											
												
												
													使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审
													使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。
												
												下载
												
											
										

关键资源（如首屏图标、字体、CSS）的  必须带 as 属性（如 as="font"），否则浏览器无法正确预加载

 必须含 width 和 height（或使用 aspect-ratio CSS），避免 CLS（布局偏移）
内联大段 JS/CSS（>1KB）应移出 HTML；<script></script> 标签禁止放在  里且无 defer 或 async

SEO 敏感字段（、、）必须由服务端或框架统一注入，禁止硬编码死值

是否与团队约定的模板/组件规范对齐？
HTML 审查不是挑刺，而是确认“我们说好怎么写，现在确实这么写了”。脱离团队规范的“正确写法”反而增加认知负担和 merge 冲突。

组件命名统一用 kebab-case：，而非  或 

数据属性统一前缀：data-testid（用于测试）、data-track（用于埋点），禁用 data-* 随意命名
条件渲染逻辑必须收敛到组件层，HTML 模板中禁止出现 v-if / {% if %} 等模板语法混用（除非项目明确允许）
所有 class 名必须来自设计系统 token 或 BEM 规范（如 btn--primary），禁用临时 class 如 fix-margin、temp-hide


最难的不是记住每条规则，而是在 PR 里快速判断：这段 HTML 是“刚好能用”，还是“经得起三个人在不同设备、不同辅助工具、不同加载状态下同时验证”。每次审查多花 30 秒确认 alt、role、width/height 和 class 命名，比上线后修一个 a11y 投诉或 SEO 掉量省十倍力气。