应限制修饰符数量与粒度，仅保留互斥、枚举明确的业务语义修饰符（如--primary、--disabled），尺寸/主题等视觉变量交由CSS自定义属性接管，并确保修饰符始终与Block类名共存于同一className中。
修饰符太多导致CSS规则爆炸怎么办
一个 Block 出现超过 5 个 --modifier 类（比如 button--primary、button--secondary、button--large、button--small、button--outline、button--filled……），基本就失控了。这不是语义问题，是规则碎片化——每个修饰符都得单独写一遍 padding、border、color，体积和维护成本直线上升。
真正该保留的修饰符，必须满足：互斥、有限枚举、业务语义明确。例如按钮只保留 button--primary、button--disabled、button--loading 这三类；尺寸、边框风格这些视觉变量，交给 CSS 自定义属性接管。
- 禁用像素级修饰符：
button--padding-12、button--radius-4这类完全不可维护，PurgeCSS 也识别不了使用场景 - 修饰符必须和 Block 同级使用：
<button class="button button--primary">✅，不能写成<span class="button--primary">❌ - 所有修饰符类名必须在 JS 层统一收口，避免组件内手动拼接：
className={`${styles.button} ${props.variant === 'primary' ? styles['button--primary'] : ''}`
为什么 button--theme-dark 比 .dark-theme .button 更可靠
看到样式依赖父级类名（如 .dark-theme .button）才生效，说明这个样式没内聚——它本不该知道外部主题状态，而是该由 button 自己声明“我支持暗色主题”。否则一旦页面结构微调（比如把按钮挪到另一个容器里），样式就断了。
button--theme-dark 把状态显式绑定到组件自身，既可预测，又利于 PurgeCSS 推断使用范围（只要 JS 里用了它，CSS 就不会被删）。更重要的是，它让构建时注入变量成为可能：
立即学习“前端免费学习笔记（深入）”；
.button {
background-color: var(--button-bg, #007bff);
}
.button--theme-dark {
--button-bg: #333;
}
这样，CSS 文件里只有一套规则，不同主题靠变量切换，而不是生成两套几乎相同的规则。
HTML 中类名太长怎么收住不膨胀
不是靠缩写（比如把 user-profile__avatar--size-large--theme-dark 缩成 up-av-lg-dk），而是靠限制 Modifier 的表达粒度和引入运行时控制。
关键判断点：如果一个类名里出现两个以上 --，基本可以停一下——是不是把布局细节（size）、外观细节（theme）、交互状态（is-loading）全塞进去了？这违反 BEM 本意。
- 只允许布尔态或枚举值修饰符：
--disabled、--sm、--outline，禁用描述性短语：--very-big-and-centered - 状态类（如
--loading）应由 JS 控制开关，而不是靠人工在 HTML 里写死多个组合 - 用
data-属性配合 JS 注入 CSS 变量，把部分修饰符逻辑从 HTML 移到样式层：<button class="button" data-theme="dark" data-size="lg">
PurgeCSS 为什么对 BEM 修饰符特别敏感
PurgeCSS 不是智能 AI，它只做一件事：扫描你代码里所有字符串字面量，找有没有匹配 CSS 类名的。所以 button--primary 能被安全删除，前提是它真的出现在 JS/TS/HTML 的字符串中；而 button--size-xl 如果只是写在 CSS 里、没在任何地方引用，就会被误删。
更麻烦的是，修饰符一旦和 Block 解耦（比如只写 class="button--primary"，没同时带 button），PurgeCSS 就无法建立上下文关联，tree-shaking 失效。
所以最易被忽略的一点：所有修饰符类名，必须和对应 Block 类名在同一个 className 字符串里共存，哪怕只是空格分隔。否则，你写的每一个 --modifier，都在悄悄增加生产包体积，且毫无意义。
