HTML代码质量规范需平衡可执行性、团队接受度与长期维护收益，而非一味从严；强制闭合所有标签易引发重复闭合或Git噪音，建议仅强制闭合易错位的块级容器，其余交由Prettier统一处理；class命名不绝对禁用样式词，但新模块须用语义名，存量可渐进重构；lang属性需动态同步子节点及第三方组件，配合data-lang-sync兜底；工具链（Prettier/ESLint/CI）自动校验比人工宣贯更有效。
HTML代码质量规范不是越严越好，而是要在可执行性、团队接受度和长期维护收益之间找平衡点。硬推“完美规范”反而导致绕过、注释掉、或写两套代码——这才是真实维护成本飙升的源头。
为什么强制闭合所有标签反而增加出错概率
HTML5 允许省略某些结束标签（如 </li>、</dt>、</html>），但强制补全在实际协作中容易引发两类问题：
- 编辑器自动补全与手写混用，导致重复闭合，比如
<p>text</p></p> - 多人修改同一段列表时，有人删了
</li>，有人又加回去，Git diff 大量噪音，真正语义变更被淹没 - 对
<img>、<input>这类自闭合标签加斜线（<img />）虽无害，但和 HTML5 规范不一致，且部分模板引擎（如 Nunjucks）会报 warning
建议：只强制闭合 <div>、<section>、<article> 等易嵌套错位的块级容器；列表项、段落等由 Prettier 统一格式化即可，不纳入人工检查项。
class 命名要不要禁止 “left”、“red” 这类样式词
完全禁止会抬高新人门槛，也违背渐进式改进原则。关键不是“能不能用”，而是“谁来改、什么时候改”：
立即学习“前端免费学习笔记（深入）”；
- 新功能模块必须用语义名，如
user-avatar、error-banner，这是硬约束 - 存量页面中
float-left类若仅用于布局且无 JS 绑定，可暂留，但禁止新增 - 一旦该 class 被 JS 选中（如
document.querySelector('.red-alert')），就必须立刻重构为.alert--error或类似 BEM 变体 - CI 流程中加一条简单检查：
grep -r "class=\".*[a-z]\+-[a-z]\+\"" src/ | grep -E "(red|blue|left|right|top|bottom)"，只告警不阻断
lang 属性动态切换时最容易漏掉的环节
lang 不只是写在 <html lang="zh-CN"> 里就完事。多语言站点常见失效场景：
- Vue/React 组件内用
v-html或dangerouslySetInnerHTML渲染富文本时，未同步设置子节点的lang，导致屏幕阅读器读错语种 - 第三方评论组件（如 Disqus）加载后，其 iframe 内容仍用初始
lang，无法响应页面语言切换 -
document.documentElement.lang = 'en'执行后，未触发languagechange事件监听，依赖该事件的字体加载逻辑失效 - 服务端渲染（SSR）页面中，
lang值来自请求头，但客户端 hydration 后未校验是否一致，造成 SSR 与 CSR 不匹配警告
最轻量的兜底方案：在根元素上加 data-lang-sync 属性，JS 初始化时遍历所有含该属性的子元素，批量更新其 lang。
规范落地最难的不是条文本身，而是默认行为与工具链的咬合程度。Prettier 配好、ESLint 插件装好、CI 检查设成 warning 而非 error——这些比开会宣贯“必须怎样”管用十倍。人会犯错，工具不会。
