前端工程师在维护大规模组件库时，往往会遇到一个看似简单却极其棘手的问题：调整两条 CSS 规则的顺序，竟能在不改变任何业务逻辑的情况下破坏组件表现。这种 “隐式顺序依赖” 正是 CSS 状态管理面临的核心困境 —— 当 hover、disabled、active、dark mode、容器查询等多种状态同时作用于同一元素时，浏览器依赖特异度与源码顺序的组合规则来决定最终样式，而这种机制在复杂组件系统中几乎无法人工预测。
特异度与源码顺序的双重不确定性
让我们从一个经典例子出发。考虑一个同时具有 hover 和 disabled 状态的按钮：
.btn:hover { background: dodgerblue; }
.btn[disabled] { background: gray; }
这两个选择器的特异度均为（0, 1, 1），当按钮同时处于 hover 和 disabled 状态时，浏览器不得不回退到源码顺序作为最终裁决。如果:hover 规则位于 [disabled] 之后，被禁用的按钮会呈现蓝色；反之则保持灰色。这种行为并非 bug，而是 CSS 级联机制的固有特性，但在真实项目中，当状态数量从一两个扩展到十几个时，维护者必须在脑海中构建一个完整的 “特异度矩阵” 来预测任意状态组合下的最终样式。
真正的问题在于，这种不确定性会随着组件系统的增长而指数级放大。黑暗模式可能来自根属性、媒体查询或两者叠加；间距可能在窄容器中改变但仅限平板宽度；破坏性变体在 hover 时表现不同但加载时除外；父主题可能切换子组件的覆盖规则。每一条规则单独来看都清晰可控，但它们之间的交互面才是 CSS 开始变得脆弱的节点 —— 一次看似无害的重构可能转化为源码顺序 bug，扩展现有组件意味着重新打开已经认为 “解决” 了的特异度问题。
声明式状态映射的编译策略
Tasty 这个工具试图从根本上改变这一状况。它的核心理念非常直接：与其让开发者手动编写相互竞争的选择器，不如让开发者描述属性的可能状态映射，而由编译器负责生成确保该优先级无歧义的选择器。
具体实现上，开发者使用一种领域特定语言声明状态优先级：
const Button = tasty({
as: 'button',
styles: {
fill: {
'': '#primary',
':hover': '#primary-hover',
':active': '#primary-pressed',
'[disabled]': '#surface',
},
},
});
这段代码明确表达了优先级顺序：disabled 最优先，其次是 active，然后是 hover，最后是默认状态。编译器生成的 CSS 选择器则通过否定伪类实现真正的互斥：
.t0[disabled] { background: var(--surface-color); }
.t0:active:not([disabled]) { background: var(--primary-pressed-color); }
.t0:hover:not(:active):not([disabled]) { background: var(--primary-hover-color); }
.t0:not(:hover):not(:active):not([disabled]) { background: var(--primary-color); }
每条规则都通过:not () 排除了所有优先级更高的状态，从而彻底消除了选择器重叠的可能性。开发者只需要维护状态映射的优先级声明，编译器自动生成正确的选择器矩阵。
可落地参数与工程实践要点
将这种确定性思路引入实际项目时，以下参数和监控点值得关注。首先是状态优先级声明规范：建议在组件开发初期就明确定义所有可能状态的优先级顺序，并将其作为组件契约的一部分记录在案，避免后期随意添加状态导致优先级混乱。其次是特异度上限控制，团队可以约定单条规则的最大特异度不超过（0, 2, 0），超出阈值的选择器需经代码评审。
在持续集成环节，建议添加自动化检测：在 CI 流程中集成 css-specificity-check 或 stylelint-plugin-no-unsupported-selectors 规则，当新增样式规则的特异度与现有规则产生冲突风险时发出警告。对于已采用 Tasty 或类似工具的项目，应监控编译产物的选择器数量增长趋势 —— 理想情况下，互斥选择器的数量应与状态数量的线性组合成正比，而非指数级爆炸。
回滚策略方面，当样式回归发生时，首先检查是否新增了状态声明或修改了优先级顺序，而非直接回退到传统 CSS 写法，因为放弃编译器保证可能引入更隐蔽的回归。对于使用 CSS-in-JS 方案的项目，可以考虑逐步迁移策略：先在不涉及状态交集的简单组件上试点，确认编译产物符合预期后再扩展到复杂交互组件。
小结
CSS 状态管理的不确定性并非 CSS 语言本身的缺陷，而是声明式 UI 需求与级联机制之间的结构性张力。Tasty 代表的编译器方案通过将状态优先级声明与选择器生成解耦，让开发者回到了描述 “应该是什么” 的正确抽象层级，而把 “如何实现” 的复杂性交给机器处理。对于构建需要多年迭代、变体增长、主题扩展的复杂组件系统而言，这种确定性保证的价值会随着时间推移而持续累积。
资料来源：本文主要参考 Tasty 官方文档与作者 tenphi 在 dev.to 分享的《Why I spent years trying to make CSS states predictable》，该文详细阐述了 CSS 状态冲突的根源与 Tasty 编译器的设计思路。