一个UI片段能否作为Block，取决于其功能独立性而非视觉复杂度；若删除后导致页面缺失完整功能（如search-form、user-avatar），即为Block，否则仅为临时容器。
一个UI片段能不能当Block，只看它能不能独立存在
不是看它多大、多复杂，而是删掉它，页面是否缺失某个完整功能。比如去掉 search-form，搜索功能就没了；去掉 user-avatar，用户身份标识就断了——这种就是 Block。反之，如果它只是视觉上“看起来像一块”，但没独立语义（如 section-2、main-content），那它大概率只是临时容器，不该建模为 Block。
常见误判点：
-
header-left-btn：带位置词，不是名词，无法跨上下文复用 -
card__footer：如果 footer 里包含操作按钮、时间戳、状态标签，且这些在别处也复用（如列表项 footer、弹窗 footer），那它就不该是 Element，而该升格为item-footerBlock -
nav__link：若 link 在页头、侧边栏、页脚都出现，且样式/行为一致，它就该是独立的nav-linkBlock，而不是依附于某个 nav
Element 嵌套超过一层，基本说明它该升 Block 了
card__header__title 或 user-card__avatar__wrapper__inner 这类命名，违反 BEM 扁平层级原则，也暴露 DOM 实现细节。真正该问的是：这个“子结构”有没有可能被单独复用或控制状态？
实操判断清单：
立即学习“前端免费学习笔记（深入）”；
- 它是否在 ≥2 个不同父组件中出现？→ 是，升 Block
- 它是否有自己的 JS 状态（如展开/收起、加载中）？→ 是，升 Block
- 它的样式是否频繁被后代选择器覆盖（如
.card .card__header .card__header__title）？→ 是，说明它已脱离父级语义约束 - 它是否带交互动作（如 close、clear、edit）？→ 动作词命名（
__close）本身已是信号，应拆为modal-close-button或search-clear-button
Modifier 出现在多个 Block 里，说明它其实该是工具类
如果发现 button--error、input--error、alert--error 同时存在，而且样式几乎一样，那 --error 就不是某个 Block 的专属变体，而是跨组件的视觉状态——这时应该抽成 is-error 工具类，而非 Modifier。
Modifier 的合理使用边界：
-
button--primary✔️：描述按钮自身变体，语义明确、可复用 -
button--disabled✔️：影响按钮自身渲染，移除后仍可显示默认态 -
user-card--loaded✖️：这是生命周期状态，不是视觉变体；JS 应控制data-loaded或is-loaded类 -
card__title--highlight✖️：Element 不该直接挂 Modifier；应由card__title card__title--highlight并列使用，且确保 highlight 是 card 内部可配置的视觉选项
重构已有碎片化结构时，先改类名再动样式
不要一上来就重写 HTML 结构。先做最小改动：
- 把所有
block__elem__sub统一替换成block__sub（前提是 sub 确实属于该 Block） - 若 sub 实际可独立（如
card__badge在用户卡片、通知气泡、商品标签里都出现），新建badgeBlock，CSS 中删除所有.card .card__badge这类后代选择器，只保留.badge单类规则 - Vue/React 中检查 JSX 里是否有字符串拼接生成非法类名（如
`card__${type}__icon`），这类必须拦截并替换为card__icon card__icon--${type}
真正容易被忽略的是：第一个 __ 之后又出现 __，往往不是设计使然，而是“先加个 class 应急”的惯性结果。PR 评审时盯住这个信号，比事后重构管用十倍。
