BEM不会过时，因其解决样式冲突与结构脆弱的工程底线问题；它通过块、元素、修饰符的命名规范保障可维护性、协作效率与样式稳定性。
它不会过时，因为BEM解决的不是“怎么写好看”的问题，而是“怎么让样式不互相打架、不随HTML结构一动就崩”的工程底线问题。
为什么 .user-card h3 比 .user-card__title 更容易出事
前者依赖 DOM 层级和标签类型：一旦把 h3 换成 div，或者把 .user-card 嵌进另一个容器里，样式就断了；后者只认类名，挪位置、改标签、抽组件，只要类名还在，样式就生效。
- 常见错误现象：
.header h2和.article h2在全局作用域下互相覆盖，查半天才发现没加命名空间 - 真实使用场景：微前端项目中多个团队并行开发，各自维护独立模块，
.button这种泛名根本不敢用 - 性能影响：层级选择器（如
.modal .content .title）比单类名匹配慢，浏览器要逐层向上回溯
--disabled 为什么必须和 button 共存，不能单独用
修饰符不是独立样式单元，它描述的是“某个块/元素的变体状态”，脱离基础类就失去语义和作用范围。单独写 .button--disabled 会导致样式无法继承基础按钮的尺寸、边框、字体等共性规则。
- 必须写成：
<button class="button button--disabled"> - 禁止写成：
<button class="button--disabled">（丢失基础样式，且违反 BEM “修饰符不可独立存在”原则） - 容易踩的坑：Sass 中滥用
&生成嵌套选择器，比如.button { &--disabled { ... } }看似简洁，但若误写成.button:hover &--disabled，就生成了非 BEM 的复合选择器，破坏约束
为什么 __ 和 -- 不能简写成单字符
双下划线和双连字符是 BEM 的语法分隔符，不是装饰。它们让解析器（人或工具）能无歧义地切分类名结构：search-form__input--disabled 可明确拆为 block=“search-form”，element=“input”，modifier=“disabled”；而 search-form_input_disabled 或 search-form-input-disabled 都存在多义性（比如 form-input 是 block 还是 element？）
立即学习“前端免费学习笔记（深入）”；
- 工具链依赖这个结构：stylelint 插件靠它校验命名合法性，VS Code 插件靠它自动补全元素类名
- 团队协作中，新人看到
__就知道“这是某块的内部部件”，看到--就知道“这是某种开关态”，不用翻文档猜意图 - 压缩后类名仍是扁平字符串，gzip 对重复前缀压缩效率很高，所以长度不是实际瓶颈——真正卡住项目的，是命名模糊带来的维护成本
BEM 最难坚持的不是写法，而是拒绝用标签选择器、拒绝嵌套、拒绝在类名里塞样式值（比如 --bg-blue）。这些约束看着反直觉，但每一条都在堵一个真实发生过的线上样式事故入口。
