--rounded 比 --rounded-full 更危险，因其语义模糊、不可枚举、新增变体易致契约断裂；而 --radius-sm/md/full 等键值修饰符语义明确、可排序、可校验，且天然支持主题扩展与工具链自动化。
因为键值对格式（如 --size-large、--theme-dark）能明确表达“可枚举的变体”，避免命名体系在后续迭代中断裂——它不是为了看起来更“规范”，而是防止你三个月后被迫重写所有圆角类。
为什么 --rounded 比 --rounded-full 更危险？
表面上 --rounded 简洁，但一旦业务需要支持“小圆角”和“大圆角”，你就得新增 --rounded-sm 和 --rounded-lg，此时原 --rounded 的语义立刻模糊：它是“默认”？“中等”？还是“全圆角”的别名？CSS 里无法自动推导优先级，开发者只能靠文档或记忆维护，工具链也无法校验。
而从一开始用 --radius-sm / --radius-md / --radius-full，每个值都是独立、可列举、可排序的语义节点，新增变体不破坏已有契约。
-
--radius-前缀锁定维度（圆角），后缀只允许语义词（sm、lg、full），禁用单位（--radius-4px）和程度副词（--radius-very-big） - 值必须可枚举：如果未来要加暗色模式，
--theme-dark可自然延伸出--theme-high-contrast，但--dark就无法判断它是主题、状态还是颜色值 - 构建时可通过正则校验：
/--(radius|theme|size)-[a-z]+/能覆盖全部合法键值修饰符，而--rounded无法被同一规则捕获
--disabled 和 --size-large 不能混用同一套逻辑
布尔修饰符（--disabled）回答“是不是”，键值修饰符（--size-large）回答“是哪一种”。把尺寸写成布尔形式（如 --large）会导致两个问题：
立即学习“前端免费学习笔记（深入）”；
- 无法叠加：你不能同时有
--large和--small，但可以有--size-large和--size-small，它们互斥且可被 CSS 变量统一接管 - 语义坍缩：
--large离开上下文就失去意义——是按钮宽？字体大？容器高？而--size-large至少表明这是“尺寸维度下的 large 变体” - 响应式友好：
--size-mobile是反模式，但--size-xs+@media控制生效范围，逻辑分离清晰
键值修饰符如何与 CSS 自定义属性配合？
真正让键值修饰符落地的不是命名本身，而是它和 var(--size-large) 的映射关系。例如：
:root {
--size-small: 0.75rem;
--size-medium: 1rem;
--size-large: 1.25rem;
}
.button--size-large {
font-size: var(--size-large);
}
这样，修改主题只需覆盖变量，无需改任何类名。而布尔修饰符（--disabled）通常直接控制样式声明，不依赖变量。
- 键值修饰符应尽量对应一个 CSS 变量，哪怕初始只用一次——这是为将来主题切换、密度调节、无障碍字号放大留接口
- 禁止用键值修饰符模拟布尔行为，比如
--state-success，这其实是--status-success，且应搭配aria-live或data-status同步语义 - 工具链可基于键值前缀自动生成变量声明文件，比如扫描所有
--color-*类，输出colors.css，布尔类则无法自动化
最常被忽略的一点：键值修饰符的“值”必须是稳定语义，不是临时业务字段。比如 --category-electronics 看似合理，但如果分类会动态增删，它就该由 JS 注入 data 属性控制，而非固化进 CSS 类名——BEM 修饰符只承载设计系统内收敛的、可维护的变体集合。
