BEM中的block是能独立存在且有明确语义职责的功能单元，如button、card；命名用小写中划线名词，禁止嵌套element，modifier仅作用于自身节点，is-active等状态类应限于JS瞬时状态且避免样式耦合。
什么是BEM里的block，不是“大盒子”而是独立功能单元
很多人一看到block就下意识想成“一个div容器”，结果写出来全是header-blockcontent-block这种伪BEM。其实block必须满足两个条件：能独立存在、有明确语义职责。比如button、card、search-form——它们不依赖父级样式也能正常工作，换到别的页面照样用。
常见错误现象：main-content被当block，但“主内容区”本身没行为逻辑，只是布局占位；真正该拆的是它里面的article-list或pagination。
- 判断标准：删掉这个元素，页面是否缺失某个可交互/可复用的功能？是 → 可能是
block - 命名规则：用名词，小写+中划线，避免
my-old-等前缀 - 禁止嵌套定义：
block__element__element不存在，BEM只允许一层__
block__element为什么不能单独存在，以及怎么避免“过度拆分”
element是block的组成部分，天生不具备独立性。写成card__title没问题，但单独给title写一套CSS，在其他地方复用时必然和上下文脱节——它可能在card里左对齐，在list-item里又需要居中，这时就得靠modifier或重写，反而更麻烦。
使用场景：当你发现某段HTML结构总是一起出现（比如card__image+card__body+card__footer），且样式强耦合于card整体状态（如card--horizontal影响所有子元素排版），这就是典型的element边界。
立即学习“前端免费学习笔记（深入）”；
- 不推荐：
button__icon+button__text→ 拆太细，button本身已足够原子化 - 推荐：
form__field+form__submit→ 字段和提交按钮在表单中有明确分工与样式联动 - 性能提示：过多
__层级不会影响运行时，但会让开发者grep时多敲几次Ctrl+F
block--modifier和block__element--modifier到底改谁的样式
修饰符（modifier）永远只改变它所挂载的那个节点的行为或外观，不波及父级或兄弟节点。这是BEM最常被误解的一点——有人以为button--large会自动让button__icon也变大，其实不会。
错误现象：nav--vertical写了，但nav__item还是横排，因为没给nav__item--vertical或通过JS动态加类；或者直接在nav--vertical .nav__item里写样式，破坏了BEM的隔离原则。
- 正确做法：修饰符类必须显式加在对应DOM节点上，
<div class="nav nav--vertical"><div class="nav__item nav__item--vertical"> <li>参数差异：<code>--disabled通常禁用交互+视觉降级，--theme-dark只改颜色，二者语义不同，别混用 - 兼容性注意：CSS变量可以辅助修饰符切换主题，但别用
:is(.button--primary, .button--secondary)这种写法绕过BEM结构 - 允许：
menu-item.is-open { max-height: 500px; } - 禁止：
.is-open .menu-item__icon { transform: rotate(90deg); }→ 这属于menu-item__icon--open该干的事 - 容易被忽略的点：服务端渲染时，
is-类如果没同步输出，首屏会出现状态闪烁；建议用data-属性配合CSS属性选择器替代部分场景
遇到is-active这类布尔状态类，还算是BEM吗
严格说，is-active不是BEM原生概念，它是状态类（state class），和BEM的modifier并存但职责不同。button--primary是设计决策，is-active是运行时状态。混用容易导致样式覆盖混乱，比如button--primary.is-active和button--primary.button--active两套逻辑打架。
真实项目里很难完全不用is-类，关键是控制范围：只用于JS驱动的瞬时状态（选中、加载中、校验失败），且不写任何尺寸/间距/颜色以外的样式。
