会，但影响程度取决于使用规模和上下文——单个 div 或 p 选择器几乎无感，而全量匹配、高频重绘或移动端低端设备上，div 这类标签选择器可能比 .card 慢 20%–30%。
会，但影响程度取决于使用规模和上下文——单个 div 或 p 选择器几乎无感，而全量匹配、高频重绘或移动端低端设备上，div 这类标签选择器可能比 .card 慢 20%–30%。
为什么标签选择器在大规模 DOM 中变慢？
浏览器匹配 CSS 是从右到左进行的。当写 article > div > p，浏览器先找所有 p 元素，再逐个向上查父级是否为 div、再查其父是否为 article。DOM 节点越多，遍历开销越明显。
-
div属于“元素选择器”，时间复杂度是O(n)，即需扫描全部div节点 - 现代浏览器虽做了并行优化，但无法改变本质：它必须检查每个同名标签，不能像
.btn那样靠哈希表O(1)定位 - 在百万级节点页面（如后台管理列表页、可视化画布），标签选择器的样式计算耗时可翻倍
什么时候用标签选择器还算合理？
它不是“坏”，而是“适用场景窄”。真正适合它的，只有两类：
- 全局基础重置，比如
* { margin: 0; padding: 0; }（尽管通配符更差，但标签选择器在此类规则中已是次优解） - 语义化强、数量可控的顶层容器，例如
header、main、footer—— 它们在 DOM 中天然唯一或极少，且浏览器对这些 HTML5 标签有内置缓存优化 - 配合
:is()或:where()做轻量聚合时，如:is(h1, h2, h3) { line-height: 1.4; }，比写三条规则更简洁，性能也接近单条
容易被忽略的坑：看似省事，实则埋雷
很多团队用 button 替代 .btn，觉得“反正就几个按钮”，但问题常在迭代中暴露：
立即学习“前端免费学习笔记（深入）”；
- 第三方组件注入了未加 class 的
button，样式意外污染（比如弹窗确认按钮突然变宽） - Sass 嵌套生成
.modal div button，关键选择器退化为button，导致全量扫描 - React/Vue 组件中动态渲染大量
li，又用ul li设置 hover 效果，滚动时触发频繁重排 - 媒体查询里重复写
@media (max-width: 768px) { div { font-size: 14px; } }，等于每次断点切换都重跑一遍全量匹配
.post-content p {
margin-bottom: 1rem;
}
/* ✅ 更安全：限定作用域，关键选择器是类名 */
.post-content > p {
margin-bottom: 1rem;
}
/* ⚠️ 稍好一点：子选择器减少祖先遍历，但关键选择器仍是 p */
真正要警惕的，不是“能不能用 div”，而是“有没有意识到它正在成为性能瓶颈的放大器”——尤其当你开始用 Lighthouse 测出 “Avoid large layout shifts” 或 DevTools Coverage 显示大量 CSS 规则命中率低于 5%，那往往就是标签选择器在悄悄拖后腿。
