BEM修饰符（如button--primary）比.btn.primary更易控制覆盖逻辑，因其是语义绑定的单类名，避免多类依赖导致的样式断裂；实操中应紧耦合块名、禁用嵌套修饰符、显式声明、封装第三方组件、接受类名长度换取确定性，视觉变量优先用CSS自定义属性。
为什么 button--primary 比 .btn.primary 更容易控制覆盖逻辑
因为 BEM 的修饰符（--primary）是单个类名，和基础块（button）绑定在语义和层级上，不会意外被其他选择器干扰。而传统写法中 .btn.primary 依赖两个独立类共存，一旦漏加、错加或被 JS 动态移除其中一个，样式就断了。
实操建议：
- 修饰符必须和块名紧耦合，写成
button--loading，不写成button-loading或loading-button - 避免嵌套修饰符，比如
button--primary--disabled—— 这会增加维护成本，改用button--primary button--disabled组合更清晰 - 所有修饰符类都应在 HTML 中显式声明，不靠 JS 拼接字符串生成（容易漏空格或重复）
如何用 BEM 重写第三方组件库的默认样式而不污染全局
关键是把第三方类名当“块”来对待，而不是试图覆盖它。比如 Ant Design 的 ant-btn，你可以封装一层：my-button ant-btn，再用 my-button--secondary 控制变体。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 直接写
.ant-btn { color: red }—— 会污染所有按钮，且后续升级可能失效 - 用
.ant-btn.my-button这种组合选择器 —— 权重高但可读性差，还可能因第三方结构调整而断裂
正确做法：
- 用
my-button作为外层容器，内部用my-button__icon等子元素结构化内容 - 修饰符只作用于
my-button，如my-button--size-large，不侵入ant-btn内部 - 需要微调时，用
my-button--has-icon .ant-btn-icon定位，保持路径明确、范围可控
block__element--modifier 这种命名在 CSS 里真的不会太长吗
会，但长度换来了确定性。BEM 类名长，是因为它把“谁、在哪、什么状态”全塞进一个字符串里，省去了查上下文的成本。开发时多敲几个字符，调试时少翻三屏代码。
性能与兼容性影响很小：
- CSS 解析器对类名长度不敏感，现代浏览器无实际性能损耗
- 所有主流构建工具（Vite、Webpack）都能压缩类名（如用
cssnano+postcss-bem-linter），上线后不影响体积 - 真正卡顿的是选择器深度，不是类名长度 —— 所以坚持单类名，禁用
.block .element这种后代选择器
什么时候该放弃 BEM 修饰符，改用 CSS 自定义属性
当修饰行为是纯视觉变量（颜色、间距、圆角），且变化频繁、跨组件复用时，--color-primary 比 button--primary 更灵活。
但要注意边界：
- 自定义属性适合“值”，不适合“逻辑”。比如
--is-disabled: true是反模式，应该用button--disabled控制显隐/交互态 - 不要混合使用：一个组件内既用
button--large又用style="--size: large"，会让样式来源不可追溯 - 如果项目已用 Tailwind，BEM 修饰符可退为语义层（
button--cta），视觉由class="bg-blue-600 px-4"承担，两者分工明确
BEM 修饰符不是银弹，它管的是“这个按钮此刻代表什么角色”，而不是“这个按钮要多宽多高”。后者交给设计系统变量或 utility class 更合适。
