直接写 .button 会因 CSS 全局作用域导致样式污染，BEM 通过 block__element--modifier 命名规范隔离组件样式，守住“不互相污染”底线。
为什么直接写 .button 会出问题
因为 CSS 是全局作用域，.button 在任何地方都生效。项目一变大，组件复用一多，A 组件的 .button 就可能意外覆盖 B 组件的 .button 样式，尤其是用了 !important 或深层嵌套后更难排查。
常见错误现象：margin 突然变大、color 被改掉、hover 效果在不该触发的地方触发——往往不是代码写错了，而是命名撞车了。
使用场景：React/Vue 组件库、多团队协作项目、需要长期维护的中后台系统。
- BEM 不是强制规范，但它是目前最易落地、工具链支持最好、新人也能快速看懂的命名方案
- 它不解决所有样式问题（比如动态主题），但能守住「不互相污染」这条底线
- 别用
btn这类缩写，BEM 要求语义明确：button就是button，不是btn
__ 和 -- 到底怎么分，什么时候该用 _
__（双下划线）只用于表示「元素」，即组件内部不可再拆分的子节点；--（双短横）只用于修饰符，表示状态或变体；_（单下划线）不是 BEM 官方符号，尽量不用，除非你明确在用某套扩展规则（比如 button_theme-dark 这种旧式写法）。
立即学习“前端免费学习笔记（深入）”；
错误示例：header__nav-item_active —— 这里 nav-item 是另一个组件，不该塞进 header 的命名空间里；正确做法是让它自己叫 nav-item，独立维护。
参数差异：BEM 不关心你用 SCSS 还是 CSS-in-JS，但如果你用 @apply 或 clsx 拼类名，必须严格对齐结构，否则调试时根本看不出哪个类对应哪块逻辑。
-
search-form__input✅（input 是 search-form 的直属子元素） -
search-form__input--disabled✅（disabled 是 input 的一种状态） -
search-form__input_error❌（单下划线不标准，应为--error） -
search-form__input-group❌（group 不是原子元素，应该单独定义为input-group）
要不要加前缀，比如 myproject-button
一般不用。BEM 的块名（block name）本身已承担命名空间职责，button 在项目里就代表「我们自己的按钮组件」。加前缀反而让类名膨胀、编辑器自动补全变卡、Git diff 更难读。
例外情况只有两个：
一是你正在写一个要发布到 npm 的 UI 库，必须防第三方项目里的同名类；二是老项目改造，已有大量非 BEM 类名，靠前缀做过渡隔离。
性能影响几乎为零，但可维护性差别很大：类名越短，CSS 文件体积越小，DevTools 里找元素越快；过长的前缀会让开发者下意识跳过读类名，反而增加误改风险。
- 推荐：直接用
button、modal、user-card - 谨慎：用
myapp-button，除非你真有跨项目复用需求 - 拒绝：
ui-button-v2-legacy-override这种“自解释型混乱”
遇到动态类名或条件拼接怎么办
JSX/TSX 里用 clsx 或模板字符串拼 BEM 类名没问题，但得守住结构底线：不能把修饰符逻辑塞进块名里，也不能把元素名硬编码成变量。
错误写法：className={`button--${type}`} —— type 是业务字段（如 'primary'），不是样式修饰符，这会让设计系统失控；正确方式是提前定义好 button--primary、button--secondary，然后映射。
兼容性注意：CSS Modules 和 Tailwind 都能配合 BEM，但别混用。比如在 button.module.css 里写 .button__icon，就别再用 tw-xxx 去覆盖它的 display，否则审查元素时你会看到两套规则打架。
- 动态部分只允许出现在修饰符位置：
button--${size}、button--is-loading - 块名和元素名必须字面量固定：
button__label不能写成${prefix}__label - Vue 的
:class或 React 的className里，优先用对象语法控制开关，比字符串拼接更安全
真正难的不是记住 BEM 规则，而是在接口改三次、UI 稿一天一版、后端字段名和前端类名永远对不上时，还坚持把 __ 和 -- 打对。这时候少一次手抖，半年后就少一个查不出的样式 bug。
