id仅应用于锚点跳转、label绑定和高频单点js访问三类场景；其余布局、状态、交互等均应使用class，避免重复id导致的样式覆盖难、aria失效、焦点错乱等问题。
别用 id 给样式或批量操作做准备，它天生不是干这个的；日常开发中，90% 以上该用 class 的地方硬塞了 id，结果是样式难覆盖、JS 行为不可靠、团队协作时命名打架。
document.getElementById() 返回第一个匹配项，不是报错
这是最隐蔽也最常被忽略的坑：HTML 允许你写两个 id="submit-btn"，浏览器不会警告，但 document.getElementById("submit-btn") 永远只返回 DOM 中第一个。表单验证后焦点跳转总卡在第一个字段、ARIA 关联失效、label 点击没反应——往往就是这儿出的问题。
- 服务端模板（如 Django、EJS）循环渲染时，容易漏掉
id动态拼接，生成一堆重复id -
aria-labelledby、for属性依赖id唯一性，重复就等于“断连” - 想查有没有重复
id？控制台跑一句：[...new Set([...document.querySelectorAll('[id]')].map(el => el.id))].length !== document.querySelectorAll('[id]').length
.my-class 和 #my-id 的 CSS 权重差一个数量级
#header 权重是 0,1,0,0，.header 是 0,0,1,0——前者比后者高 10 倍。这意味着你写十个 .nav-link.nav-link.nav-link 都压不过一个 #main-nav。组件化开发里，第三方 UI 库或微前端子应用一旦用了 id 写样式，你的覆盖规则基本宣告失效。
- 用
class能自然支持 BEM（如.button--large）、状态类（.is-loading）、多类叠加（class="card card--featured js-modal-trigger"） -
id无法叠加，也不能表达语义分组，硬要用只能靠data-属性补位，比如data-component="search-form" - 性能上，
getElementById是哈希查找，快；但querySelector('.search-input')在现代浏览器优化后，差异已不明显，别拿“性能”当滥用id的借口
锚点跳转和 label 关联是 id 的合法且必要场景
只有这三类用途，id 才不可替代：
- 页面内锚点：
@#@#@#@#@#@#@#@#@#@0+<section id="contact"></section> -
label绑定表单控件：<label for="email">邮箱</label>+<input id="email"> - JS 高频单点访问容器元素，比如
<canvas id="game-canvas"></canvas>或主应用挂载点<div id="root"> <p>其余所有情况——布局、状态、主题、交互反馈、组件类型——全交给 <code>class。连data-属性都比乱用id更合适，因为它不参与样式权重、不干扰可访问性、还能带语义。class 值里不能有空格，但可以有连字符和下划线
class="btn primary large"是三个独立 class；class="btn-primary"是一个 class。很多人误以为btn-primary是“复合类”，其实它就是一个字符串，CSS 里必须写成.btn-primary，而不是.btn .primary（后者是后代选择器，完全两码事）。- 错误写法：
button.btn-primary意图选“带btn-primary类的 button”，但少了个空格，实际变成选标签名为buttonbtn-primary的元素 - 正确写法：
button.btn-primary（无空格）表示“标签是 button 且 class 含btn-primary”；button .btn-primary（有空格）才表示“button 内部的.btn-primary元素” -
class值不能含制表符、换行、空格，否则 HTML 解析器会截断；但-、_、数字、大小写字母都合法
真正麻烦的不是记不住区别，而是团队里有人坚持“ID 更快”“ID 更直观”，结果在组件库里埋下重复 ID、高权重样式、ARIA 断连这些静默故障——它们上线后才爆发，而且很难复现。
- 错误写法：
