modifier组合完全合法，是bem设计本意；须确保各modifier作用于同一block或element、修改不同css属性、均用单类名选择器，避免构建工具误删，并对叠加态显式声明覆盖规则。
Modifier组合是否合法？
完全合法，而且是BEM设计的本意之一。只要每个Modifier都作用于同一个Block或Element，并且它们修改的CSS属性不重叠，就能安全叠加。
为什么.btn--lg.btn--primary有时颜色失效？
根本不是BEM不支持组合，而是CSS规则写错了——两个修饰符同时设置了background-color或border，后加载的规则覆盖了前者。
-
.btn--lg只应改padding、font-size、line-height -
.btn--primary只应改--btn-bg、--btn-text、border-color - 所有修饰符必须用单类名选择器：
.btn--lg { }，不能写成.btn .btn--lg { }（权重低且违反BEM） - 构建工具如
cssnano可能误删重复类名，需在配置中禁用mergeLonghand
如何避免.btn--disabled和.btn--loading叠加时出问题？
这两个状态常共存（比如请求失败后按钮既禁用又显示加载态），但关键不在“能不能加”，而在CSS是否显式覆盖冲突点。
- HTML中必须写全：
class="btn btn--primary btn--disabled btn--loading" -
.btn--disabled控制pointer-events、opacity、cursor -
.btn--loading只处理伪元素、position: relative和动画，不碰背景或文字色 - 叠加态要单独声明：
.btn--disabled.btn--loading { opacity: 0.5; }，否则默认opacity可能被覆盖 - PurgeCSS等工具会删掉动态添加的类，safelist需包含正则：
/btn--(disabled|loading|error)/
为什么.btn--primary.btn--large比.btn--primary-large更可靠？
.btn--primary-large看似省事，实则是反模式：它把两个独立语义硬编码成一个新名字，破坏了正交性与可维护性。
- 一旦设计要求所有
--large按钮统一增加line-height，你得全局搜索替换--primary-large、--secondary-large……而不是只改一处.btn--large - JS动态控制时，
btn--${variant}-${size}容易拼错或注入非法值；而分开控制btn--${variant}和btn--${size}更安全、可校验 - 类名长度不是问题，语义断裂才是——
--primary-large无法表达“这是个主按钮，且尺寸大”，它只是一个无法拆解的字符串
真正容易被忽略的是：Modifier之间没有隐含顺序或层级关系，它们只是平行开关。写btn--loading btn--disabled和btn--disabled btn--loading效果完全一致，但团队必须约定一种书写习惯并坚持，否则HTML里类名顺序混乱会加大diff噪音和审查成本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
