CSS类选择器和ID选择器有什么区别

ID选择器用于强制唯一标识（如表单关联、锚点跳转），类选择器用于可复用的样式与行为分组；ID高优先级破坏维护性，JS查询容错性差，仅在语义刚性场景才必须使用。

类选择器和ID选择器的语义与约束完全不同

根本区别不在写法（.btn vs #header），而在 HTML 规范对 class 和 id 属性的定义：一个允许多次复用，一个强制全局唯一。

这意味着：class="save-btn" 可以出现在 10 个按钮上，浏览器照常匹配；而 id="save-btn" 出现在两个元素上，document.getElementById('save-btn') 只返回第一个，CSS 样式也只生效于第一个——不是“错”，而是规范如此。

1. id 是锚点、ARIA 关联、Shadow DOM 引用的基础设施，比如 <label for="email"> 必须对应 <input id="email">
2. class 是样式和行为分组的通用载体，React/Vue 的 class 绑定、BEM 命名、CSS-in-JS 都基于它
3. 重复 id 不会报错，但会让 getElementById、querySelector('#xxx')、aria-labelledby 失效或不可预测

CSS 中 ID 选择器的高优先级会破坏样式维护

ID 选择器的 specificity 是 100，一个 #sidebar .nav-link 就压倒了 10 个类组合（如 .container .sidebar .nav .link.active）。这不是“更强”，而是更难覆盖。

常见现象：!important 加了也没用，因为权重差跨层级——#modal .close（100+10=110）比 body .modal .close（1+10+10=21）高太多，!important 只在同级比较中生效。

1. 上线前必须删掉临时加的 !important，否则后续改样式会陷入“不断加权重”的死循环
2. 想提高权重，优先拆解结构：把 .card-title 改成 .card > .title（10+1=11 → 10+1=11，但更明确），而不是硬塞 #card .title
3. 组件库或框架中，几乎看不到用 ID 写样式——不是不能，是主动规避这种不可控性

JS 查询时 ID 并不比类“更快”，但更危险

理论上 getElementById 是哈希查找，getElementsByClassName 是遍历，但现代浏览器优化后，差异通常低于 0.01ms。真正的问题在于容错性。

当模板动态渲染出多个 id="tooltip"，document.getElementById('tooltip') 永远只拿到第一个；而 document.querySelectorAll('.tooltip') 能拿到全部，配合 forEach 或事件委托也更自然。

1. 事件委托场景下，用 document.querySelector('.item-list').addEventListener(...) 比 document.getElementById('list').addEventListener(...) 更健壮——DOM 变动后仍有效
2. 测试定位推荐 document.querySelector('[data-testid="save-button"]') 或带 js- 前缀的 class（如 .js-save-btn），而非依赖 ID
3. 框架里直接用 ref（Vue）或 useRef（React），根本绕开查询逻辑

什么时候真该用 ID 而不是 class

不是“性能更好”或“看起来更正式”，而是场景刚性需要唯一标识。

比如表单 <label for="phone"> 必须指向 <input id="phone">；页面内跳转 <a href="#section3"> 必须有对应 <h2 id="section3">；Web Components 中 this.shadowRoot.getElementById('input') 是标准 API 调用方式。

1. 这些地方不用 ID，就违反 HTML 语义或 API 合约，不是风格问题，是功能缺陷
2. 但它们和“给按钮加背景色”完全无关——那个任务交给 .btn-primary 就行
3. 混淆用途的典型错误：把 id="header" 当作样式钩子，结果某天要加第二个 header，整个逻辑就崩了

实际开发中，class 是默认选项，ID 是特例通行证——用之前先问一句：这里是否真的需要全局唯一、不可复制的标识？如果不是，就别碰 id。