html不是“写完就能跑”的静态文件，因为它直接决定可访问性、seo效果、ssr稳定性及组件hydration行为；常见div深层嵌套、aria-label拼写错误、alt空字符串、form缺label等问题在本地不报错，却在无障碍测试或搜索引擎抓取时集中暴露。
为什么 HTML 不是“写完就能跑”的静态文件
HTML 在前端工程里常被当成“辅助内容”，但实际它直接决定可访问性、SEO 效果、服务端渲染（SSR）稳定性，甚至影响 React/Vue 组件的 hydration 行为。团队里常见 div 嵌套 8 层、aria-label 拼写错误、alt 空字符串、form 缺少 label 或 for/id 不匹配——这些在本地开发几乎不报错，却在无障碍测试或搜索引擎抓取时集中暴露。
Code Review 中必须盯住的 4 类 HTML 问题
不是所有 HTML 都需要人工逐行审，重点应落在影响交付质量的硬性缺陷上：
-
语义断裂：用
div冒充button、section被写成div class="section"、列表不用ul/ol而全靠 CSS 实现；这类问题会破坏屏幕阅读器流式导航 -
可访问性缺失：表单控件无关联
label、图片缺alt（空字符串alt=""仅适用于纯装饰图）、tabindex="0"滥用导致焦点顺序混乱 -
结构污染 SSR/CSR 边界：在 React 中直接写
innerHTML注入 HTML、Vue 模板里混用v-html且未过滤、服务端返回的 HTML 包含未闭合标签（如漏掉），会导致 hydration mismatch 错误 -
跨浏览器兼容隐患：使用实验性属性如
inert（IE 完全不支持）、popover（Chrome 114+）、dialog未配showModal()调用而仅靠 CSS 控制显隐
如何把 HTML 评审嵌入现有 Code Review 流程
不需要新增 checklist 文档或会议，而是把规则转化为 PR 描述模板 + 自动化提示 + Reviewer 的聚焦点：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- PR 描述强制包含「本次修改涉及的 HTML 结构变更说明」，例如：
将用户头像区域从 div 改为 figure + figcaption，而非模糊写“优化 UI” - CI 中接入
axe-coreCLI 扫描 HTML 片段（非整站），命令示例：npx axe --reporter=json --output=axe-report.json src/**/*.html，失败时阻断 PR 合并（仅检查严重级critical和serious） - Reviewer 不必通读全部 HTML，只查三处：
<form></form>是否每个<input>都有<label for="xxx"></label>；<img>的alt值是否为空或冗余（如alt="logo"）；组件根节点是否用了语义化标签（避免<div class="card">，改用 <code><article class="card"></article>）容易被忽略的边界场景
最常翻车的地方不在主流程，而在边缘分支和“临时方案”：
- 服务端模板（如 EJS、Nunjucks）中拼接 HTML 字符串时，
若含字符会直接破坏结构，必须转义；但 <code>（不转义）若没做 XSS 过滤，可能注入恶意<script></script> - 国际化（i18n）文案插入 HTML 时，
<span>{{ t('welcome_msg') }}</span>若翻译值含<br>，需确认框架是否允许 HTML 插值，否则渲染为纯文本 - 微前端场景下，子应用输出的 HTML 片段若包含
<style></style>标签或内联style属性，可能污染主应用样式作用域，应约定禁止内联样式，统一走 CSS-in-JS 或 scoped CSS
HTML 评审不是追求“语法完美”，而是守住可访问性底线、避免 SSR/Hydration 失败、防止模板注入漏洞。真正难的不是写对标签，是在快速迭代中让每个人对
alt、for、role这些属性保持条件反射式的敏感。 - 服务端模板（如 EJS、Nunjucks）中拼接 HTML 字符串时，
