ID选择器理论更快但日常差异可忽略，真正影响性能的是类选择器的深度嵌套；ID的核心限制在于全局唯一性和高优先级，适用场景是表单关联、锚点跳转、Shadow DOM引用和自动化测试定位。
ID选择器比类选择器快，但差异在现代浏览器中几乎不可测
浏览器对 #id 选择器的查找是直接通过哈希表定位的，而 .class 需要遍历匹配节点（尤其当它出现在复杂选择器中时）。但这个“理论优势”只在极端场景下有意义——比如页面有上万元素、且频繁调用 document.querySelector('#my-id')。日常开发中，两者性能差值通常低于 0.01ms，别为这点差异重构 CSS 或 JS 逻辑。
类选择器在实际使用中更常成为性能瓶颈的源头
真正拖慢渲染或查询速度的，往往不是 .btn 本身，而是它嵌套在低效选择器里。比如：
.container div ul li a:hover .icon
这类深度嵌套的类选择器会让浏览器从右往左反复回溯匹配，比单个 #header 慢几个数量级。而 ID 选择器极少被这样滥用，因为一个 ID 理论上只应出现一次，没人会写 #nav #sidebar #user-menu 这种东西。
- 避免用
.class写过深的层级（超过 3 层就该警惕） - 慎用通配符或属性选择器搭配类，如
[data-type] .item -
#id在querySelector中确实更快，但getElementsByClassName返回的是实时集合，而getElementById返回单个元素——这本身也影响后续操作成本
CSS 中 ID 选择器的实际限制比性能更关键
ID 的语义约束和复用限制，远比“快不快”影响更大：
立即学习“前端免费学习笔记（深入）”；
- ID 必须全局唯一，一旦动态插入重复 ID（比如模板渲染出多个
id="modal"），CSS 规则可能只作用于第一个，JS 查询（document.getElementById）也只返回第一个 - CSS 中
#id的优先级（specificity）是 100，高于类（10），容易意外覆盖其他样式，调试时难定位 - 现代组件框架（React/Vue）默认用 class 控制样式，ID 多用于可访问性（
aria-labelledby）或 JS 锚点，而非样式主力
什么时候真该选 ID 而不是 class
不是因为快，而是因为场景需要唯一标识：
- 用
label[for="email"]关联表单控件时，id="email"是必需的 - 页面内跳转锚点，如
<a href="#section2">，目标必须是<h2 id="section2"> - Web Components 或 Shadow DOM 中，需用 ID 做内部元素引用（配合
this.shadowRoot.getElementById） - 自动化测试中，用 ID 定位元素比 class 更稳定（class 易因 UI 调整而变，ID 更倾向保持语义不变）
性能不是决定 ID 还是 class 的首要因素；语义准确性、维护性和框架约定才是。强行用 ID 替代 class 求“快”，反而容易埋下唯一性、可访问性或协作冲突的坑。
