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 面板验证样式重计算。选择器不是写给浏览器猜的结构越清楚页面越稳。