Modifier应控制可枚举、有语义且不破坏结构的样式，如opacity、cursor、--rounded等；禁用width/height、margin/padding等布局属性；布尔修饰符须极简，仅覆盖状态强相关属性。
哪些CSS属性适合用Modifier控制
Modifier不是万能开关，它只该管「设计系统中可枚举、有明确语义、且不破坏块基础结构」的样式分支。一旦越界，就会出现样式断层、权重失控或JS切换失效。
-
推荐控制：
opacity、cursor、pointer-events、background-color、border-radius（如--rounded或--radius-sm）、font-size（配合--size-small等键值型修饰符）、display（仅限显式状态，如--hidden） -
谨慎使用：
position、z-index、transform——这些容易引发布局塌陷或层叠上下文意外，应绑定到 Block 本身（如.dialog--fixed），而非随意加在元素上 -
禁止直接控制：
width/height（除非是固定尺寸变体，如--avatar-48）、margin/padding（应由 Block 或 Element 的基础类定义，Modifier 只负责“是否应用”或“哪套间距体系”，如--spacing-tight）
为什么不能用Modifier改margin或display: grid
Modifier 的语义是「状态/变体」，不是「布局重写」。把 margin 塞进修饰符里（比如 .card--no-margin），等于把容器逻辑下放给状态——后续一旦卡片嵌套进 .list--spaced，两个 margin 规则就打架；同理，display: grid 是块级布局契约，不该靠 --grid 临时开启，而应由 .card-grid 这类新 Block 承担。
- 常见错误：
.button__icon--inline强行改display: inline-flex→ 实际应归入.button--layout-inline，让整个块协调对齐 - 正确做法：Modifier 控制「是否启用某套已定义好的布局行为」，而不是现场拼装布局规则
- IE10/11 对
gap支持差？那就用.grid--no-gap切换为margin模拟，但margin值本身仍由基础类预设，Modifier 只开关
--disabled这类布尔修饰符该写哪些CSS声明
布尔修饰符（无值，仅存在即生效）必须保持极简，只覆盖「状态强相关且不可继承」的属性。多写一条，就多一分被后续主题或工具链覆盖的风险。
- 必须声明：
opacity: 0.5、cursor: not-allowed、pointer-events: none - 可以声明（视设计系统而定）：
background-color: var(--color-disabled)（用 CSS 自定义属性承接，避免硬编码） - 禁止声明：
color（应由.button__text元素自身处理）、border（若需弱化边框，应走--border-subtle键值型修饰符，而非耦合在--disabled里） - 别忘了重置伪类影响：
.button--disabled:hover必须显式覆盖掉:hover的原有样式，否则鼠标悬停时 opacity 可能跳变
键值型修饰符命名时最容易踩的坑
键值型修饰符（如 --theme-dark、--radius-full）一旦命名失当，很快会陷入「修饰符爆炸」——今天加 --rounded，明天发现要支持 --rounded-sm，后天又冒出 --rounded-pill，最终失去语义收敛。
立即学习“前端免费学习笔记（深入）”；
- 初始设计就要判断：这个变体未来是否可能扩展？如果“圆角”注定只有全圆和直角两种，用
--rounded/--square布尔型更干净；如果明确要支持 sm/md/lg/full，直接定义--radius-sm等键值型 - 值必须语义化：
--radius-full✅，--radius-9999px❌；--theme-dark✅，--bg-222❌ - 禁止数字+单位混用：
--size-16px违反 BEM 可读性原则，也阻碍 CSS 自定义属性动态注入 - 所有键值型修饰符必须在 CSS 中显式声明，不能靠 JS 动态拼接类名去“猜”是否存在
.avatar--circle，HTML 里也得同时有 .avatar，否则 border-radius: 50% 很可能因为缺少 display: block 或 overflow: hidden 而失效——这不是 CSS 写错了，是语义链断了。 
