微小团队html质量底线是语义正确、格式统一、可访问性不缺失；需用htmlhint卡住基础语义错误，同步配置.prettierrc与.editorconfig确保缩进一致，并通过axe-core cli自动化检测硬性可访问性规则，人工聚焦描述准确性与交互自然性。
微小团队不需要“大而全”的HTML质量标准，但必须守住三条底线：语义正确、格式统一、可访问性不缺失。其他规则能自动化就别靠人盯。
怎么让新人写的HTML不出基础语义错误
语义错误不是写错标签，而是用错场景——比如把导航栏写成 <div class="nav"> 而不是 <code><nav></nav>，或者用 <div onclick="submit()> 冒充按钮。这类问题靠 Code Review 效率极低，得靠工具卡住。
- 在项目里装
htmlhint，配最小化规则：强制<img>有alt、<button>不允许用onclick、标题层级不能跳级（h1后直接h3报错） - 把
htmlhint加进package.json的precommit脚本里，提交前自动跑，失败就中断 - VS Code 安装
HTMLHint插件，编辑时实时标红，比等 CI 报错快得多
为什么 Prettier 配置必须和 .editorconfig 同步
只配 .prettierrc 不够，VS Code 可能读取文件原有缩进风格，或在新建文件时用默认设置，导致同一项目里混着 2 空格、4 空格、Tab 三种缩进——Git diff 全是空格变更，毫无意义。
.editorconfig是编辑器层面的“最低共识”，必须包含：indent_style = space、indent_size = 2、end_of_line = lf.prettierrc里" tabwidth> 必须和 <code>.editorconfig的indent_size一致，否则保存时会反复重排- 把这两个文件一起放进 Git，新成员 clone 后开箱即用，不用问“缩进到底几个空格”
- CI 流程里跑
axe-coreCLI，检测color-contrast、landmark-one-main、heading-order这类硬性规则，失败即阻断上线 - 每季度抽 3 个关键页面，用 VoiceOver 或 NVDA 实际听一遍，重点看表单流程、错误提示、动态加载内容是否可感知
- 禁止在
alt=""里写“图片”或“图标”这种无效值——这是人工审查唯一必须卡死的点
哪些可访问性检查能用脚本自动过，哪些必须人工看
自动化能覆盖的只有结构型问题：是否漏 alt、label 是否绑定 for、lang 是否存在。但“描述是否准确”“焦点顺序是否合理”“屏幕阅读器读出来是否自然”，脚本无能为力。
真正难的不是定规则，而是让工具链在没人维护的情况下持续生效。一个 husky 钩子失效、一次 prettier 版本升级、甚至 VS Code 更新后插件权限重置，都可能让整套机制静默崩坏。定期手动验证钩子是否真在跑，比写十条规范更重要。
