CSS 选择器性能：别让样式匹配变成隐形税
一、选择器问题不会总是出现在小 Demo 里
CSS 选择器性能在小项目里很难显眼。页面节点少，怎么写都差不多。到了复杂后台、低代码页面或长列表，过深选择器、通配符、后代选择器叠起来，样式计算成本就会变成隐形税。
现代浏览器很强，但不是让样式表随便长。CSS 性能优化不是迷信“不能超过几层”，而是让选择器和 DOM 结构保持可控。
二、选择器匹配要结合 DOM 规模看
样式计算成本和节点数量、选择器复杂度、状态变化频率有关。列表项很多、状态频繁变化的区域，选择器要更克制。
flowchart TD A[DOM 节点数量] --> D[样式计算成本] B[选择器复杂度] --> D C[状态变化频率] --> D D --> E[渲染性能] E --> F[交互延迟]一个复杂选择器在静态页面没事，在频繁 hover、展开、过滤的页面里就可能变成问题。
三、用 Stylelint 守住基本边界
可以先用规则限制嵌套深度和选择器复杂度。
{ "rules": { "selector-max-compound-selectors": 4, "selector-max-specificity": "0,4,0", "max-nesting-depth": 3 } }规则不是为了写得“高级”，而是防止样式表慢慢变成考古现场。复杂场景可以例外，但例外要有理由。
四、选择器治理要和组件边界一起做
CSS 性能差，很多时候不是选择器本身，而是组件边界乱。父组件样式一路穿透到孙子组件，后代选择器越写越长。最后一个 class 改名，全页面都抖。
更稳的做法是组件内样式只管自己，跨组件用 token、slot 或明确 props。不要靠.page .panel .item .title这种链条表达结构。
最后，性能验证要看 Recalculate Style。Chrome Performance 里能看到样式重计算成本。别靠肉眼判断选择器是否“可能慢”。
动态 class 切换也要看范围。给根节点加一个状态 class，可能导致大范围样式重新计算；只给局部组件加状态，影响面小很多。状态表达要靠近使用位置，不要一层状态牵动全页面。
CSS-in-JS 场景也一样。运行时生成样式如果频繁插入 style 标签，会增加样式计算和内存压力。不是换个写法，选择器问题就消失了。样式方案再现代，也要看最终进浏览器的规则。
最后，治理要配合设计系统。常见间距、颜色、状态样式进入 token 和组件库后，业务页面就少写深层选择器。CSS 问题很多时候是组件资产缺失的症状。
浏览器兼容也要看。某些现代选择器写起来优雅，但在目标浏览器上支持不完整，或者需要额外降级。性能治理不能只看最新 Chrome。目标用户用什么环境，就在什么环境下验收。
还要避免过度局部化。每个组件都复制一份类似样式，会减少选择器复杂度，却增加 CSS 总量。治理目标是边界清楚，不是把重复代码藏进每个角落。
最后，样式变更要进视觉回归。选择器优化看似不改视觉，实际很容易影响边缘状态。hover、disabled、focus、dark mode 都要覆盖。CSS 改动没有截图回归，就是裸奔。
还要给公共样式设边界。全局 reset、主题类和工具类可以存在，但要清楚哪些目录能改。公共样式一旦被业务随手加规则，迟早变成全站隐形耦合。
五、总结
CSS 选择器性能要结合 DOM 规模和状态变化频率看。用规则限制复杂度，用组件边界减少深层穿透，再用 Performance 面板验证样式重计算。选择器不是写给浏览器猜的，结构越清楚，页面越稳。
