HTML元素属性顺序规范对团队协作效率提升

class必须排在id前面，因CSS权重和浏览器解析逻辑要求class作为组件识别主线索、id仅作单点锚定，错误顺序会导致选择器冲突与JS批量操作失效。

class为什么必须排在id前面

不是为了“看起来顺”，而是因为浏览器解析和CSS权重的实际逻辑：class更常复用、更易被JS操作，前置后一眼就能识别组件类型；id语义强、全局唯一，放后面当“锚点补充”更符合直觉。写成<div id="header" class="site-header">容易让人误以为id才是主标识，实际开发中常导致选择器冲突或JS查询错位。

常见错误现象：document.querySelector("#header")能取到，但document.querySelectorAll(".site-header")漏掉其他同类元素——因为团队习惯只靠id定位，结果class命名随意、复用率低，最终组件无法批量操作。

• class用于样式复用和JS批量操作，应始终作为第一视觉线索
• id仅用于单点锚定或getElementById，不应承担组件识别职责
• eslint-plugin-html默认校验顺序，不按此写会在CI阶段报attribute-order警告

data-*属性必须带业务前缀，否则等于没写

data-id="123"这种裸名在协作中毫无意义——三个月后连自己都记不清这是用户ID、订单号还是SKU。它本质是前端与后端/业务逻辑的契约接口，必须自带上下文。

真实踩坑场景：后端返回{"user_id": 123, "status": "active"}，前端却写<div data-id="123" data-status="active">，结果多人并行开发时，另一个模块也用data-id存商品ID，DOM里出现两个同名data-id，JS逻辑全乱。

立即学习“前端免费学习笔记（深入）”；

• 正确写法：<div data-user-id="123" data-user-status="active">
• 更稳妥方案：<div data-api-source="user/profile" data-user-id="123">
• 用stylelint配置selector-attribute-pattern规则，拒绝不含业务前缀的data-*，提交即拦截

Prettier自动重排属性顺序，但要注意三个例外

靠人记顺序不如让编辑器干——Prettier可强制执行class→id→data-*→src/href→title/alt→role/aria-*→tabindex，但有三处必须手动干预：

第一个坑：<textarea>和<script>永远不能自闭合，否则内容丢失；Prettier默认格式化可能加/，需在prettier.config.js里设htmlWhitespaceSensitivity: "ignore"兜底。

第二个坑：Vue SFC中<img src="x" />会被Volar报warning，但删掉/后Prettier又可能格式化掉换行——必须统一工具链行为。

第三个坑：布尔属性如disabled，Prettier不会帮你删="disabled"，得靠eslint-plugin-html配no-unused-expressions类规则主动清理。

• 所有项目启用Prettier + husky pre-commit hook，避免格式争议进入CR
• 禁用editor.formatOnSave对.vue文件的自动触发，改用保存后手动Shift+Alt+F（VS Code）确保可控
• 在package.json脚本里加"format:html": "prettier --write "**/*.{html,vue}""，方便批量修复历史代码

空行不是风格问题，是逻辑分界信号

连续写五个<div>没人看得出哪段属于表单、哪段属于侧边栏。空行本质是视觉锚点，不是“看着舒服”，而是降低认知负荷的关键分隔符。

典型反例：一个<section>里塞了8个<div>，没有空行也没有注释，CR时同事问“这个data-form-step到底控制哪块？”，你得花两分钟翻DOM结构才能答上来。

• 模块之间用1个空行（如<header>和<main>之间）
• 页面级大区块之间用2个空行（如不同<section>之间）
• 响应式@media块前加空行，调试时一眼定位影响范围

注意：Prettier默认不插空行，得配合prettyhtml或自定义插件，否则靠人工维持极易失效。