Modifier不应包含width: 100%等布局属性，因其职责是描述状态或视觉变体（如--disabled、--primary），而非控制容器尺寸；布局应由外层容器或布局工具类管理，否则破坏组件复用性与弹性。

Modifier里写width: 100%为什么是错的

因为Modifier本该描述状态或视觉变体（比如--disabled、--expanded），而不是接管容器职责。一旦在.button--full-width里硬写width: 100%，这个按钮就失去了“作为独立功能单元”的弹性——它只能塞进某个固定宽度父容器里，否则会撑破布局或被截断。

常见错误现象：.card--sidebar里加max-width: 320px，结果卡片挪到modal里时缩得太小；或者.form--inline强制display: flex，导致嵌套在grid布局中时子元素对齐失效。

• Modifier应只改变自身表现，不干涉父/兄弟容器的尺寸约束
• 布局行为（宽高、定位、内外边距）应由组件外层容器或布局工具类（如u-flex、l-grid-col）控制
• 如果真需要适配不同上下文，用Block级响应式类（如.card--responsive）配合CSS容器查询，而非把布局逻辑塞进Modifier

怎么区分“视觉变体”和“布局占位符”

关键看这个类名是否能在脱离当前DOM位置后，依然表达明确、可复用的功能语义。比如.button--primary在任何页面、任何容器里都表示“主操作按钮”，而.button--sidebar一离开侧边栏就失去意义——它本质是布局占位符，不是状态。

使用场景：当你发现一个Modifier命名里出现top、left、sidebar、main、section-2这类词，基本可以判定它越界了。

• ✅ 合规：--compact（密度）、--outline（描边风格）、--dark（主题色系）
• ❌ 违规：--in-header、--full-bleed、--mobile-only（后者应交由媒体查询或容器类控制）
• 性能影响：含布局属性的Modifier会迫使CSS引擎频繁重排，尤其在JS动态切换时；纯视觉Modifier则更易被GPU加速

遇到必须控制宽度的组件怎么办

优先拆出独立Block或引入布局抽象层，而不是让Modifier承担。比如一个“占满父容器的卡片”，问题不在卡片本身，而在它的使用方式——应该由卡片的父容器决定其宽度，而非卡片自己声明--full-width。

实操建议：

• 用容器类组合：父级加u-w-100，卡片保持.card原样
• 若需组件内建响应能力，定义.card--fluid，但CSS里只写width: 100% + min-width: 0（防flex/gird下溢出），不设max-width或padding
• 在Vue/React中，通过prop传入layout="fluid"，映射为card--fluid，但逻辑仍归属Block层级，不侵入Element

最常被忽略的一点：Modifier不是CSS重写开关

很多人以为.button--large就是“把按钮变大”，于是直接覆盖font-size、padding、line-height——但没同步调整button__icon尺寸或button__text行高，导致图文错位。这暴露了根本问题：Modifier必须显式覆盖所有相关Element的表现，不能靠“父级变大，子元素自动适应”的隐式假设。

真正合规的做法是，在CSS中写完整链路：.button--large .button__icon { width: 24px; height: 24px; }，或更优解：用CSS自定义属性统一驱动，比如--button-size: 48px，再由.button__icon读取计算值。这样Modifier才真正可控、可预测、可测试。