HTML代码质量差是跨团队协作的硬伤，需用工具链强制约束：语义化标签（如<header><nav><main>）、带业务前缀的class命名（user-avatar）、规范id/data属性（loginForm、data-product-id）、Prettier+ESLint自动化检查。
跨团队协同时，HTML代码质量差、命名不统一，不是“风格偏好问题”，而是直接导致合并冲突、样式覆盖、组件复用失败的硬伤。必须用可落地的约束代替口头约定。
HTML标签语义化不是加分项，是协作前提
多人维护同一套页面结构时，<div class="header"> 和 <header> 的差异会放大成协作成本：前者需要所有人记住“这个div就是header”，后者浏览器、屏幕阅读器、CSS选择器、甚至VS Code的智能提示都自动识别其角色。
- 导航区域必须用
<nav>，而不是<div id="nav">—— 否则下游团队写nav a选择器会失效 - 主内容区统一用
<main>，禁用<div id="content">或<section class="main">—— 避免不同团队对“主内容”定义不一致 -
<button>必须用于可交互元素，禁用<div onclick="...">—— 否则无障碍测试工具（如 axe）会报错，且键盘焦点逻辑不一致
class命名必须带业务域前缀，且全小写中划线分隔
没有前缀的 btn、card、modal 在跨团队项目里等于“全局污染”。A团队写的 .card 是商品卡片，B团队的 .card 是用户资料卡，合并后样式互相覆盖，调试时间翻倍。
- 命名格式强制为
domain-component，例如user-avatar、product-card、order-status-badge - 禁止使用下划线
user_avatar或驼峰userAvatar—— CSS类名不区分大小写，驼峰会出错；下划线在部分预处理器（如 Sass）中需转义 - 复数名词直接用复数，如
user-list、file-attachments，不缩写为users或files
id和data属性命名要明确作用域与类型
id 在 DOM 中必须唯一，但跨团队项目里常因命名随意导致冲突；data- 属性若不加约束，会变成“私有协议黑洞”。
立即学习“前端免费学习笔记（深入）”；
-
id只用于 JS 明确绑定的锚点或表单关联，命名用 camelCase，如loginForm、searchInput—— 不用于纯样式控制 -
data-属性必须带业务前缀和类型标识，如data-product-id="123"、data-user-role="admin"，禁用data-id="123"这类模糊命名 - 布尔型 data 属性用
data-loading而非data-is-loading—— 符合 HTML5 原生习惯，JS 判断更简洁：el.hasAttribute('data-loading')
Prettier + ESLint 配置必须锁定 HTML 规则，不能只靠人工提醒
靠“大家自觉”在跨团队场景下必然失效。工具链必须强制拦截常见错误。
- Prettier 配置中启用
htmlWhitespaceSensitivity: "css"，避免空格差异引发 Git 冲突 - ESLint 插件
eslint-plugin-html启用规则：html/indent（强制 2 空格）、html/quotes（双引号）、html/no-self-closing（禁用<img />写法，统一为<img>） - CI 流程中加入
npx prettier --check "**/*.html"和npx eslint "**/*.html"，任一失败即阻断合并
最容易被忽略的其实是 data 属性的语义一致性——同一个业务字段，在 A 团队叫 data-order-no，B 团队叫 data-orderId，C 团队叫 data-oid，后端接口字段映射和前端状态管理就会散成碎片。这类细节不写进配置、不跑自动化检查，光靠文档没人会看。
