不用。bem中block嵌套时类名不带父级前缀，因block间是平级复用关系而非父子继承；如header内search-form应写为，而非header__search-form。
Block嵌套时类名要不要带父级前缀
不用。BEM中Block之间是平级复用关系，不是父子样式继承关系。比如header里放search-form，正确写法是<header class="header"><form class="search-form"></form></header>，而不是header__search-form。
- 常见错误现象：
dashboard__user-card__avatar——这其实是三个独立Block：dashboard、user-card、avatar，强行加前缀会让类名膨胀、复用失效 - 判断依据：这个子结构是否在别处（如弹窗、侧边栏）也单独出现过？是 → 它就是独立Block
- 它有没有自己的状态（如
is-loading）、事件（如onSubmit）、或需要独立动画控制？有 → 不该被父Block“吞掉” - 它的样式是否依赖父Block的具体实现？比如
user-card在dashboard里左对齐，在profile页里居中？那说明它本就不该被dashboard定义
多个Block共存一个DOM节点时怎么写class
用BEM官方支持的mix（混合）语法：一个元素可以同时携带多个Block或Element的类名。这是合法且推荐的做法，不是hack。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 例如卡片内有个状态徽标，既属于
card的视觉流，又需在别处复用：<div class="card status-badge status-badge--online"> <li>这里<code>card和status-badge都是Block，各自维护样式与逻辑，不耦合 - 避免写成
card__status-badge——这会让status-badge失去跨上下文复用能力 - 如果
status-badge在card里有特殊尺寸或边距，应通过card--compact .status-badge这类组合选择器微调，而非改命名 -
mix不等于无序堆砌：只混真正语义相关的Block，比如button button--primary user-action-button就容易混乱，应收敛为user-action-button user-action-button--primary - 如果看到
card__body__list__item__text这种超长名，大概率是list本该是独立Block，却被降级成了card的内部元素 - 真实场景中，后台权限菜单、多级弹窗、动态表单字段组等天然嵌套深，但样式不该跟着“套娃”
- 若确实无法拆分（如遗留系统），可用Modifier表达上下文变体：
button--in-card，而非card__body__button - 禁止用Sass嵌套生成
.card .card__body .button这类选择器——它权重虚高、调试困难，且违背BEM“一个元素一个类”的原则 -
comment是最外层块（每条评论都是独立块），comment__content、comment__author只描述当前块的元素 - 嵌套回复用另一个
comment块，加修饰符区分状态：comment--nested - 通过DOM层级（如
.comment > .comment）控制缩进或继承，而非靠类名嵌套 - JS查询时，
el.querySelector('.comment--nested')比el.querySelector('.comment__reply__content')更可靠——后者在实际DOM中可能根本不存在reply节点
嵌套太深但又不想拆出新Block怎么办
优先重构HTML结构，而不是妥协命名。BEM允许Block嵌套任意层级，但不鼓励靠DOM深度表达逻辑关系。
评论列表这类递归嵌套结构怎么处理
直接用comment--nested修饰符标识嵌套评论，保持类名扁平；comment__reply__content违反BEM原则，因reply非独立块，且导致权重过高、查询困难、复用性差。
