bem能防止全局样式污染，但依赖严格命名和作用域不越界；它仅通过语义化命名建立边界，无技术强制隔离，一旦层级错乱或classname漏传仍会穿透。
全局样式污染了组件，BEM真能拦住吗
能拦，但前提是命名严格、作用域不越界。BEM本身不提供技术隔离，它只靠命名约定制造“语义边界”——一旦block__element--modifier写错层级、或在CSS-in-JS里漏传className，照样穿透。
- 常见错误：把
header__title直接写成.title，或在另一个sidebar块里复用同名__title却没加前缀 - 使用场景：适合中大型项目中多个团队共用同一套CSS文件，或需要长期维护的后台系统
- 性能影响几乎为零，但过度嵌套（如
form__field__label__text）会增加选择器权重，也违背BEM本意
CSS类名怎么写才算合规的BEM
核心就一条：所有类名必须从block开始，且__element和--modifier不能脱离父级独立存在。
-
search-form✅ 是block；search-form__input✅；search-form--active✅ -
search-form__input--error✅（modifier修饰element）；但search-form--error__input❌（modifier不能当block用） - 禁止跨block复用element名：
button__text和card__text必须是两个独立类，不能共用text - 工具可辅助：VS Code插件
BEM Helper能自动补全，但无法阻止手写错误
遇到CSS-in-JS或Shadow DOM还要用BEM吗
要，但方式得变——BEM是思维模型，不是CSS文件格式。
- 在
styled-components里，仍应导出SearchForm、SearchFormInput等组件名，对应类名保持search-form和search-form__input - Shadow DOM中，BEM类名依然有效，但无需担心全局污染，此时重点转为：统一命名风格便于调试，比如DevTools里一眼看出
user-card__avatar--large属于哪个模块 - 容易踩的坑：用
css-modules时误以为不用BEM，结果写出styles.button和styles.button在不同文件里冲突——这时BEM式命名（styles.userButton/styles.adminButton）反而更安全
为什么改了BEM类名，旧样式还在生效
大概率是缓存、未清理冗余规则，或CSS加载顺序导致低权重选择器被高权重覆盖。
- 检查是否写了
.search-form__input { ... }又写了.search-form .input { ... }——后者虽不符合BEM，但浏览器照解析，且可能权重更高 - 构建工具如Webpack可能把旧CSS chunk缓存住了，改完类名后清掉
node_modules/.cache和dist再构建 - 浏览器开发者工具里右键禁用某条规则，看是否立即消失；如果没反应，说明那条规则根本没匹配上，或者被
!important锁死了 - 最隐蔽的坑：CSS预处理器里用了
@extend或@include，实际生成的CSS类名和你写的BEM名对不上
.btn，整个隔离就塌一半。真正难的不是写对名字，是让所有人持续写对。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
