直接改.btn导致错乱是因为CSS无模块化边界，.btn全局生效；应拆分为.btn--large等修饰符，分离设计变体（--primary）与状态（is-loading），避免耦合；第三方库用BEM容器限定作用域。
为什么直接改.btn会导致其他按钮错乱
因为多数项目里.btn是全局复用的基础类，一改全改。比如你只是想让「提交按钮」变高一点，结果侧边栏的「取消按钮」也跟着变高，甚至弹窗里的「确认按钮」文字被截断——这不是样式没写好，是选择器作用域失控。
根本原因在于CSS天然没有模块化边界，.btn在哪儿都能生效，没人拦着它。
- 别在通用类上加
height、padding、font-size等影响尺寸的声明 - 把视觉差异拆成独立修饰符，比如
.btn--large，而不是.btn.large - 修饰符只负责“叠加变更”，不覆盖基础行为（如
.btn--large只加height和padding，不碰background或border）
.btn--primary和.btn--primary.is-loading该不该嵌套写
不该。BEM修饰符（--xxx）和布尔型状态（is-xxx）语义不同：前者描述**设计变体**（主按钮、次按钮），后者表达**运行时状态**（加载中、禁用）。混在一起写，比如.btn--primary.is-loading，会让样式逻辑缠绕，调试时分不清是设计稿改了，还是状态没清掉。
-
.btn--primary定义颜色、阴影等静态视觉特征 -
.btn.is-loading单独控制cursor: wait、opacity、伪元素加载动画 - 两者可共存，但CSS规则必须分开写，避免
.btn--primary.is-loading这种耦合选择器
用postcss-bem自动生成BEM类名靠谱吗
不推荐用于已有项目。这类工具会把&__content编译成.card__content，看起来省事，但实际掩盖了命名决策过程。你很快会发现：.card__header--small到底该修饰.card__header还是.card？工具不管这个，人得管。
- 生成器适合从零开始的脚手架，不适合渐进式改造
- 手动写BEM反而更清醒：每个
--都对应一个设计系统里的明确变体 - 真正要自动化的是校验，比如用Stylelint插件检查是否出现
.btn .icon这种非BEM嵌套
遇到第三方组件库样式冲突怎么办
别改它的.el-button，用BEM的“作用域包裹”思路：给整个组件外层加一个BEM命名容器，再用属性选择器限定范围。比如.form-page__upload-area .el-button比直接覆盖.el-button安全得多。
- 优先用
[class^="el-"]或[class*="el-button"]做局部限定，避免污染全局 - 如果必须覆盖，用
.my-form .el-button--primary而非.el-button--primary - 注意Vue组件的
scoped只作用于单文件组件，对el-button这种外部引入的无效
BEM修饰符不是语法糖，是把“这个样式只在这里起效”的意图写进名字里。一旦开始偷懒写.btn.red，副作用就从第一个修改开始积累。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
