CSS选择器本身不慢，但写法不当会导致浏览器大量无效匹配；关键是从右往左匹配，应让关键选择器尽量窄、具体、靠类名驱动，避免泛滥标签限定和深层嵌套。
直接说结论：CSS选择器本身不“慢”，但写法不当会让浏览器做大量无效匹配，拖慢渲染。关键不是删掉哪些选择器，而是让浏览器用最少步骤定位到目标元素。
为什么选择器要从右往左匹配
浏览器解析 nav .menu-item a:hover 时，并不是先找 nav，再往下找子元素——它先找所有 a:hover，再逐个往上查父级是否含 .menu-item，再查祖先是否是 nav。越靠右的选择器（即“关键选择器”）匹配范围越广，开销越大。
-
a:hover可能命中几十甚至上百个链接，每个都要回溯检查祖先结构 -
.menu-item如果是唯一类名，浏览器能快速哈希定位，效率高得多 - ID 选择器如
#header是最快的，但仅限单例场景，别为每个按钮都加 ID
哪些选择器组合实际伤性能
不是“用了就错”，而是在高频渲染或 DOM 量大的页面里，这些写法会明显拖慢样式计算：
-
div ul li a：关键选择器是a，全页所有<a>都被拉进来筛一遍 -
* { box-sizing: border-box }：通配符强制遍历全部节点，首屏加载时尤其卡 -
section article div p em：6 层嵌套，每层都要确认父子关系，匹配成本指数上升 -
button[disabled]：属性选择器本身没问题，但若和:hover连用，触发重绘时反复计算
真正该砍的是“没必要的层级”和“泛滥的标签限定”，不是把所有后代选择器一棍子打死。
立即学习“前端免费学习笔记（深入）”；
怎么改写才既安全又快
核心原则：让关键选择器尽量窄、尽量具体、尽量靠类名驱动。
- 把
header nav ul li a改成.main-nav-link—— 类名直接绑定语义，不依赖 HTML 结构 - 避免
div#sidebar ul.menu > li > a，ID 已唯一，#sidebar .menu-link足够 - 继承能搞定的别重复写：
body { font-family: sans-serif; }后，子元素不用再设font-family - 用
:is()替代冗余并列：h1, h2, h3 { line-height: 1.3; }可缩为:is(h1, h2, h3) { line-height: 1.3; }，减少规则数
容易被忽略的兼容性陷阱
现代写法省事，但老项目或需要支持 Safari 15.6 以下版本时，得留神：
-
:has()和:where()在部分旧版 iOS Safari 不支持，用前查 caniuse -
.card > *:not(:first-child)看似简洁，但:not()里含伪类时，某些 Chrome 版本解析异常，宁可用.card > *:not(.card-header) - 过度依赖
data-属性选择器（如[data-state="loading"]）虽语义好，但比纯类名多一次属性查找，高频动画中慎用
性能优化不是追求极致压缩，而是让关键路径上的匹配尽可能少绕弯——浏览器没那么聪明，你写的每个多余字符，它都得认真算一遍。
