BEM 本身并不能从根本上解决 CSS 全局污染，因为它没有真正的作用域机制；一旦出现同名类名，就仍然会发生冲突。再加上后代选择器滥用、修饰符使用错误等问题，也会进一步破坏样式隔离。想让 BEM 真正发挥作用，必须依赖完整的工具链与规范约束共同保障。
因为命名规范更像是一份“使用说明”，而不是彻底隔绝冲突的“防护墙”。即使 BEM 写得非常规范，.card__title 依旧可能和另一个组件中的同名 .card__title 直接冲突。浏览器不会识别你是否遵守了 BEM 规范，只会根据类名字符串是否一致来匹配样式。
为什么 BEM 类名相同就会互相覆盖？
核心原因在于 CSS 天生没有局部作用域，所有样式规则默认都是全局、扁平地加载。比如两个不同文件中都声明了 .button--primary，那么后编译或后引入的那一份样式通常就会覆盖前者，这和是否使用 __ 或 -- 命名写法没有本质关系。
- 常见问题表现：
button--primary在登录页原本是蓝色，到了商品页却被另一个团队定义成绿色，最终上线后很难快速定位是谁改动了样式 - 如果构建阶段没有启用 CSS Modules，或没有配置类名哈希（例如 Vite 中
css.modules: { generateScopedName: '[name]__[local]___[hash:5]' }}），那么 BEM 只是让全局 CSS 命名更清晰，并不能消除全局污染问题 - 在 JavaScript 中，依然可以通过
document.querySelector('.user-card__a vatar')直接查询并操作对应节点，说明暴露范围并没有真正缩小
为什么用了 BEM 还是会被后代选择器破坏？
一旦代码里出现 .search-form .input 或 & .product-card__price（这是 Sass 中常见的带空格写法），其实就等于主动打破了 BEM 所强调的样式隔离。这类选择器依赖的不是唯一类名，而是 DOM 层级结构，只要页面结构稍有调整，样式就可能立即失效，或者在不该生效的地方意外生效。
- 真实案例：把
...
之后，所有依赖.search-form .input的样式都会失效 - Sass 中的
& .product-card__price会编译成带空格的后代选择器，这实际上违背了 BEM “通过唯一类名控制样式”的原则 - 因此通常需要在 Stylelint 中启用
selector-bem-pattern，并设置为error级别，否则 CI 无法有效拦截这类问题，人工审查也很容易遗漏
为什么修饰符位置写错会让状态管理失控？
如果把 user-card__a vatar--large 当成独立状态来使用，本质上就是把尺寸变化的控制权交给了单个元素；但在 BEM 思路里，更合理的做法往往是由整个 user-card 区块统一响应状态变化。例如 user-card--compact 应该整体控制内边距、字号和图标尺寸，而不是让局部元素各自为政。
- 直接后果是：当
user-card__a vatar--large与user-card--compact同时存在时，最终谁生效往往取决于 CSS 的加载顺序，而不是命名规范本身 - Modifier 应与 block 或 element 并列组合使用，不能继续嵌套：
button--primary--loading❌，正确写法应为button--primary button--loading✅ - 元素级修饰符也不能脱离所属区块单独存在：
a vatar--large不符合规范；user-card__a vatar--large虽然合规，但前提是user-card根类必须始终存在
最容易被忽视的一点是：BEM 是否有效，并不取决于你写了多少个 __，而在于整个前端工程化流程是否把所有绕开它的路径都封住了。这里包括构建配置、CI 校验、IDE 自动补全、Stylelint 规则，甚至代码评审 checklist。只要任何一个环节缺失，BEM 就很容易沦为“看起来规范”，却无法真正解决 CSS 命名冲突和样式污染的问题。
