团队HTML难维护的根源在于缺乏可执行约束，需用Prettier+Husky统一格式、htmlhint+axe-core保障语义与可访问性，并聚焦Review于结构层级、交互语义和数据可测性三大人工关键点。
为什么团队里HTML代码越写越难维护
不是写得不够快，是改得越来越慢。常见现象包括：git diff里全是缩进和引号变化；PR里一半评论在争论class="btn-primary"该不该写成class="primary-btn"；新成员花两天搞懂一个页面的div嵌套逻辑，却只为了加个按钮。
根源不在人懒，而在缺乏可执行的约束点：没人规定data-属性必须小写、没人检查img是否漏了alt、没人阻止button被写成div onclick。这些细节不靠工具固化，单靠“自觉”或“Review时提”，必然随人员流动失效。
用Prettier + Husky堵住格式漏洞
Prettier不是选装插件，是默认开关。它能解决80%的格式争议，但前提是配置落地到每个开发者本地和CI流程里。
- 在
.prettierrc中强制设置：htmlWhitespaceSensitivity: "strict"（避免空格误删导致渲染错位）、singleAttributePerLine: true（防止长属性挤在一行难以diff） -
package.json里加脚本："format": "prettier --write \"**/*.{html,css,js}\""，并用husky绑定pre-commit钩子 - VS Code需配置
"editor.defaultFormatter": "esbenp.prettier-vscode"，且关掉其他格式化插件——多个工具打架时，Prettier会输
注意：prettier不处理语义错误，比如把nav写成div class="nav"，这类问题要靠后续工具链补位。
立即学习“前端免费学习笔记（深入）”；
用htmlhint + axe-core守住语义与可访问性底线
格式统一只是表层，真正影响长期协作效率的是语义正确性和可访问性。这两项一旦出问题，后期修复成本远高于初期预防。
- 在
.htmlhintrc中启用关键规则："tag-pair": true（强制闭合）、"attr-lowercase": true（属性名小写）、"attr-no-unnecessary-whitespace": true（防多余空格干扰ARIA属性） - CI流程中加入
npx axe-core --reporter=cli src/**/*.html，检测alt缺失、label未绑定、对比度不足等硬性问题 - 把
htmlhint错误设为exit code 1，即构建失败；axe报错不阻断构建但强制标记为“待修复”，并在PR描述自动生成检查摘要
别指望人工记住所有语义规则。article和section的区别、何时该用time而非span，靠文档不如靠htmlhint实时报错来得直接。
Code Review里只盯三件事
Review不是挑刺大赛，而是质量守门。把精力聚焦在机器无法判断、但对协作影响最大的三个点上：
- 结构层级是否合理：检查
h2后面是否跳到了h4，main里有没有意外嵌套header——这类错误htmlhint能报，但容易被忽略，需要人眼确认上下文 - 交互元素是否语义正确：
button是否用了type="button"避免表单提交、a是否只用于跳转、role是否冗余（如给button加role="button"） - 数据驱动部分是否可测试：比如
data-id是否唯一、data-testid是否暴露内部实现细节（如data-testid="sidebar-toggle-icon"比data-testid="hamburger-menu"更脆弱）
其他问题——缩进、引号、空行——全交给Prettier。如果Review还在讨论这些，说明前面的自动化没跑通，或者新成员没拉取最新.vscode/settings.json。
