id选择器在dom查询中更快，因其基于哈希表查找（o(1)），但现代浏览器对class优化成熟，实际项目中性能差异可忽略；重复id会导致获取错误元素、ssr/hydrate失败等更高风险。
ID 选择器在 DOM 查询上确实更快，但现代浏览器对 class 选择器的优化已非常成熟，实际项目中几乎感知不到性能差异。
document.getElementById() 为什么快
ID 查询走的是浏览器内部的哈希表查找，时间复杂度接近 O(1)；而 document.querySelector('.btn') 或 document.getElementsByClassName('btn') 需要遍历或构建匹配集，理论上更耗时。
- 这个优势只在「纯 JS 获取单个元素」场景下成立，且前提是 ID 确实唯一、没被重复写
- 一旦 HTML 中出现重复
id="modal"，document.getElementById('modal')仍只返回第一个——你得到的是“快但错”的结果 - 用
querySelector()写document.querySelector('#header')并不会比getElementById()快，反而多一层解析开销
class 选择器在 CSS 渲染阶段不慢
CSS 引擎（如 Blink、WebKit）早已不再“从右往左逐个匹配”，而是采用样式映射、类名索引、惰性计算等机制。一个 .card__header 和一个 #main-title 在样式计算阶段的耗时差异可以忽略。
- 真正拖慢渲染的是过度嵌套的选择器，比如
article section > div.container ul li a:hover，和它用 class 还是 ID 无关 - 浏览器 DevTools 的「Rendering」面板里几乎看不到 class vs ID 的 layout/paint 时间差
- 服务端渲染（SSR）或 hydrate 场景下，重复 ID 会导致 React/Vue 警告甚至 hydration 失败，这种错误成本远高于毫秒级查询差异
别为不存在的瓶颈做取舍
工程中真正卡顿的从来不是 class 或 ID 的选择器性能，而是：DOM 节点过多、强制同步布局（offsetTop 触发重排）、CSS 动画未启用硬件加速、或大量内联样式动态插入。
- 用
data-testid替代 ID 做测试定位，既避开重复风险，又不影响查询速度 - 需要 JS 快速获取元素？优先用
ref（React）、el（Vue）或querySelector('.js-toggle')，而不是硬塞 ID - 如果真在 10 万行表格里高频操作单个单元格，应考虑虚拟滚动或
DocumentFragment批量更新，而不是纠结选 class 还是 ID
ID 的“性能优势”只存在于教科书式微基准测试里；真实页面中，它带来的维护风险、复用限制和 SSR 兼容问题，远比那零点几毫秒更值得警惕。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
