bem通过block-element-modifier三层命名解耦视觉与功能，提升可维护性：block为独立单元，element属其结构，modifier仅控外观/状态。
为什么直接复制粘贴CSS模块总在改需求时崩盘
因为没把“视觉区块”和“功能语义”解耦。比如一个.card在列表页是横向排列，在详情页又得加阴影+圆角+内边距——硬塞一堆!important或靠父级选择器强行覆盖，后面人根本不敢动。
真正能重用的不是样式，而是「可预测的行为边界」：这个类名只管结构，那个类名只管皮肤，第三个只管状态。BEM强制你把这三层写进名字里，不是为了炫技，是让git blame时一眼看出谁动了哪块逻辑。
-
block对应独立UI单元（如header、search-form），不依赖上下文 -
element必须属于某个block（如search-form__input），不能单独存在 -
modifier只描述外观/状态变化（如search-form--compact），不改变结构
怎么把现有CSS快速转成BEM而不推倒重来
别一上来就重命名所有类。先锁死一个高频改动的模块，比如.user-card——它经常被加新字段、换背景、适配暗色模式。
拆解三步走：
.user-card → block<br>.user-card__avatar → element<br>.user-card--dark → modifier然后把原CSS里所有
.user-card .avatar这类后代选择器全干掉，换成.user-card__avatar。这样改--dark时，只动修饰符样式，不影响头像尺寸逻辑。
- 已有
.user-card .name？立刻改成.user-card__name，哪怕暂时保留旧类名双写过渡 - 遇到
.user-card.is-active这种状态类？转成.user-card--active，去掉JS里手动增删is-前缀的逻辑 - 别用
.user-card__name--large这种嵌套修饰符，大字号该归text--large这种工具类管
BEM和CSS-in-JS或Tailwind混用时最常踩的坑
核心矛盾在于「谁负责作用域隔离」。BEM靠命名防冲突，CSS-in-JS靠运行时生成唯一class，Tailwind靠原子化不组合——三者混用时，最容易出现样式打架却找不到源头。
- React里用
clsx拼BEM类名？确保block__element和block--modifier不被Tailwind的mt-4等覆盖，检查浏览器开发者工具里实际生效的顺序 - 用
styled-components写&.user-card__content？放弃。BEM的element本就不该有样式继承，直接写user-card__content作为顶层选择器 - 全局定义
.btn--primary，但组件里又用tw="bg-blue-600"？删掉后者——BEM模块的皮肤必须收敛到--primary这一层，否则“重用”只是幻觉
哪些场景下BEM反而会让代码更难维护
小项目、临时活动页、纯工具函数式组件（比如一个Icon组件只接受size和color props）——这时候硬套icon__svg--sm纯属自找麻烦。
BEM的价值在「多人协作+中长期迭代」场景里才爆发。如果你的package.json里dependencies比devDependencies还少，先别急着建components/card/目录树。
- 表单控件组合（
form-field__label+form-field__input+form-field__error）适合BEM，因为结构强约束 - 布局类容器（
container、grid）不适合，交给CSS Grid或Flex工具类更灵活 - 动画效果（
fade-in、slide-up）不该塞进BEM，抽成独立@keyframes或工具类
真正的重用，是改一个--hover修饰符，二十个按钮同时响应；而不是复制十次.card { border-radius: 8px; }再逐个找替换。边界划不清的地方，宁可多建一个文件，也别让类名承担它不该管的事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
