BEM能防CSS类名冲突，因其通过块-元素-修饰符三段式命名（如.header__title--large）实现天然隔离；需配合ESLint、Stylelint等工具强制约束，禁用后代选择器与ID/标签选择器，并匹配严格正则；与CSS-in-JS、Shadow DOM不冲突，可共存互补；超小项目或动态样式场景则不宜硬套。
为什么CSS类名重复就炸，BEM真能防住？
样式冲突不是“偶尔发生”，而是缺乏命名约束时的必然结果。BEM通过强制把组件名、元素名、修饰符拼进类名，让.header__title--large和.card__title--large天然隔离——它们根本不会被同一个CSS规则同时命中。
关键不在“写法好看”，而在编译期/人眼可判定的唯一性：只要遵循BEM规范，两个不同模块的__title就绝不可能指向同一组样式逻辑。
- 不写
.title，写.modal__title或.form__title——前缀即命名空间 - 修饰符必须带双横线
--，比如--disabled，避免和元素名混淆 - 禁止跨块复用类名：哪怕视觉一致，
.button在header里也得叫.header__button
怎么让团队真的遵守BEM，而不是写两行就漏？
靠文档和口头提醒没用。得把约束塞进开发流里——最有效的是用ESLint插件+CSS预处理器校验。
例如用stylelint-selector-bem-pattern配postcss-bem，一旦写了.user-card .name这种后代选择器，保存即报错Unexpected selector ".user-card .name"；再配合VS Code插件实时高亮违规类名，比Code Review管用十倍。
立即学习“前端免费学习笔记（深入）”；
- 禁用所有后代选择器：
.card .title→ 必须写成.card__title - 禁用ID选择器和标签选择器：
#header、h2一律不允许 - 类名必须匹配正则
^[a-z][a-zA-Z0-9]*(__[a-z][a-zA-Z0-9]*)?(--[a-z][a-zA-Z0-9]*)?$
BEM和CSS-in-JS、Shadow DOM冲突吗？
不冲突，但定位不同。BEM解决的是“人类协作中类名语义混乱”的问题，而CSS-in-JS和Shadow DOM解决的是“运行时样式泄漏”问题。它们可以共存，甚至互补。
比如在React里用styled-components，仍建议按BEM组织class结构：className={`${base}__input ${base}__input--error`}——这样调试时DOM里一眼能看懂层级，也不妨碍styled-components生成唯一哈希类名。
-
Shadow DOM内依然推荐BEM：隔离是运行时的，可读性是给人的 -
CSS Modules的composes别滥用，它会悄悄打破BEM的显式依赖关系 - 注意
:global()会绕过BEM约束，除非你明确知道在干什么
哪些场景BEM反而会让事情更糟？
超小项目（比如单页活动页）、纯工具类库（如normalize.css）、或需要极致动态样式的场景（比如可视化编辑器实时改样式），硬套BEM会增加冗余和维护成本。
这时候更该用原子类（mt-4、text-center）或CSS自定义属性驱动主题切换，而不是靠长类名堆命名空间。
- 组件粒度小于3个DOM节点时，
card__header不如直接card-header - 频繁动态拼接类名（如
className={`btn btn--${type} btn--${size}`}）容易漏掉BEM结构，不如用data-*属性配合CSS属性选择器 - 老项目增量迁移BEM，优先从新组件开始，别一上来重构
legacy.css
真正难的从来不是写对BEM格式，而是判断某个模块是否值得用BEM——它解决的是人的问题，不是机器的问题。
