html是可访问性、seo、性能和协作的第一道防线，必须语义化、可读可维护；需正确使用标签、a11y属性、预加载、尺寸声明及团队规范。
前端 HTML 代码在 Code Review 中最容易被轻视，但恰恰是可访问性、SEO、渲染性能和团队协作一致性的第一道防线。它不是“写完能跑就行”，而是必须可读、可维护、可测试、可访问。
HTML 结构是否符合语义化规范？
语义化不是为了“看起来高级”，而是让浏览器、屏幕阅读器、搜索引擎和后续维护者能准确理解内容意图。常见误用：<div> 套 <code><div> 模拟按钮或标题，<code><span></span> 替代 <button></button>，<section></section> 滥用而忽略 <article></article> 或 <aside></aside> 的实际含义。
- 按钮交互必须用
<button></button>（带原生 focus、空格/回车触发、type="button"防提交），禁用<div onclick> 或 <code><span role="button"></span> - 标题层级必须严格递进：从
<h1></h1>开始，禁止跳级（如<h1></h1>后直接<h3></h3>） - 列表内容必须用
<ul></ul>/<ol></ol>，禁止用<div> + CSS 模拟 <li>表单控件必须包裹在 <code><form></form>内，且每个<input>必须有对应<label></label>（for属性或嵌套） - 所有图片必须有
alt属性：有意义的图写描述，纯装饰图写alt=""（空字符串，不是省略） - 自定义弹窗/下拉菜单必须有
role（如role="dialog"）、aria-modal="true"、aria-labelledby，且需管理焦点流 - 动态更新区域（如搜索建议、状态提示）需加
aria-live="polite"或"assertive" - 禁用
tabindex="0"在非交互元素上——除非你已实现完整键盘操作逻辑（包括 Enter/Space、方向键、Escape） - 关键资源（如首屏图标、字体、CSS）的
<link rel="preload">必须带as属性（如as="font"），否则浏览器无法正确预加载 -
<img>必须含width和height（或使用aspect-ratioCSS），避免 CLS（布局偏移） - 内联大段 JS/CSS（>1KB）应移出 HTML；
<script></script>标签禁止放在里且无defer或async - SEO 敏感字段（
<title></title>、<meta name="description">、<link rel="canonical">）必须由服务端或框架统一注入，禁止硬编码死值 - 组件命名统一用 kebab-case：
<user-profile-card></user-profile-card>，而非<userprofilecard></userprofilecard>或<userprofilecard></userprofilecard> - 数据属性统一前缀：
data-testid（用于测试）、data-track（用于埋点），禁用data-*随意命名 - 条件渲染逻辑必须收敛到组件层，HTML 模板中禁止出现
v-if/{% if %}等模板语法混用（除非项目明确允许） - 所有 class 名必须来自设计系统 token 或 BEM 规范（如
btn--primary），禁用临时 class 如fix-margin、temp-hide
是否遗漏关键可访问性（a11y）属性？
很多 HTML 问题在视觉上完全正常，却导致屏幕阅读器无法朗读、键盘导航中断、自动化 a11y 工具报错。这不是“锦上添花”，而是合规底线。
是否存在影响渲染性能或 SEO 的硬编码问题？
HTML 是页面首次渲染的起点，某些写法会直接拖慢首屏、破坏预加载、干扰爬虫解析。
是否与团队约定的模板/组件规范对齐？
HTML 审查不是挑刺，而是确认“我们说好怎么写，现在确实这么写了”。脱离团队规范的“正确写法”反而增加认知负担和 merge 冲突。
最难的不是记住每条规则，而是在 PR 里快速判断：这段 HTML 是“刚好能用”，还是“经得起三个人在不同设备、不同辅助工具、不同加载状态下同时验证”。每次审查多花 30 秒确认 alt、role、width/height 和 class 命名，比上线后修一个 a11y 投诉或 SEO 掉量省十倍力气。
