BEM能避免样式连锁崩坏，因其强制样式作用域锁死在块内、不依赖嵌套或父级状态，并通过命名暴露结构/装饰/状态意图；合规类名需语义唯一、元素直属于块、修饰符用双连字符、禁用标签/ID选择器。
为什么BEM能避免「改一个按钮，整个表单样式崩了」
因为BEM强制把样式作用域锁死在块（Block）内部，不依赖嵌套深度或父级状态。传统写法里 .form .btn 这种选择器，一旦 .form 结构微调、或者新增同名类，.btn 就可能被意外覆盖或失效；而 BEM 要求所有样式都基于独立块名，比如 button--primary、form__input，彼此之间没有隐式依赖。
关键不是“加两个下划线”，而是用命名约定暴露样式意图：哪些是布局骨架（form__header），哪些是视觉装饰（button--large），哪些是状态开关（input--error）。这样改样式时，你一眼就知道动的是结构还是皮肤。
怎么写才算合规的BEM类名（别踩“伪BEM”坑）
常见错误是只套命名格式，但没切断样式耦合。比如写成 card__title 却还在 CSS 里写 .card__title strong { color: red; } —— 这等于又偷偷依赖了 HTML 标签，破坏了组件可移植性。
-
Block名必须唯一且语义清晰（如search-bar，不用top-search这种位置描述） -
Element必须直接隶属于 Block，不能跨层（search-bar__input✅，search-bar__results__item❌） -
Modifier只能修饰 Block 或 Element，且必须用双连字符（button--disabled，不是button-disabled） - 禁止用标签名、ID、属性选择器做样式依据（不写
div.search-bar、不依赖[data-state]）
CSS 里怎么组织 BEM 规则才不重复、不冲突
BEM 不是命名规范，是 CSS 架构策略。光有类名不够，得配合书写方式控制作用域。
- 每个 Block 对应一个独立 CSS 文件（如
search-bar.css），里面只写search-bar相关规则 - 用预处理器（Sass/Less）时，
modifier必须嵌套在对应 Block/Element 下（.search-bar--compact { ... }不能单独提出来） - 避免用
@extend复用 modifier，它会生成冗余选择器；改用mixins或 JS 控制 class 列表 - 如果要用工具校验，推荐
stylelint-selector-bem-pattern，它能直接报出.card .title这类违规写法
和 CSS-in-JS 或 Tailwind 混用时，BEM 还有用吗
有用，但角色变了。在 Tailwind 项目里，BEM 不再管具体样式值，而是定义「什么是一个可复用的 UI 单元」。比如你不会给每个按钮写一堆 bg-blue-500 hover:bg-blue-600 px-4 py-2 rounded，而是封装成 ，背后 BEM 类名（button button--primary button--lg）只负责标记语义和边界，样式由 utility class 注入。
在 CSS-in-JS（如 Emotion）中，BEM 更像一种命名契约：const StyledCard = styled.div`&.card { ... } &.card__body { ... }`。重点不是字符串拼接，而是让开发者和审查者一眼看出这个组件的内部结构是否内聚——card__footer 不该去操作 card__header 的 padding，这种约束比选择器本身更重要。
真正容易被忽略的，是 Block 的粒度。太小（比如给每个 icon 单独建 icon--home）导致维护成本高；太大（比如整个 dashboard 命名为 dashboard）又失去隔离性。判断标准只有一个：这个 Block 是否会被整体复用、是否需要独立的状态管理、是否可能被不同主题替换。其他都是次要的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
