BEM通过block__element--modifier结构使类名自带三层语义：归属、角色、状态，可替代多数注释；Element命名需避免动词与样式词，强调角色与状态解耦；第三方组件应封装Wrapper以保持语义归属清晰。
因为BEM把组件归属、结构角色、状态语义全塞进类名里，user-card__avatar--round比avatar或rounded更能让人秒懂“这是用户卡片里的圆形头像”，不用翻文档、不靠上下文、不查HTML就能推断用途。
类名自带三层上下文，替代三类常见注释
BEM的block__element--modifier结构天然携带语义边界：
-
Block名说明归属：
search-form直接表明这是搜索表单模块，不用注释“该样式用于顶部搜索” -
Element名说明角色：
search-form__clear明确是“清空操作”，不是泛称icon或btn，无需额外解释“这个图标点一下会清空输入框” -
Modifier名说明状态：
search-form__submit--loading比is-loading更安全——后者没人知道它绑在哪，而前者一眼看出作用对象和意图
哪些注释真能删，哪些必须留
团队落地BEM后，以下注释可直接删掉，且不影响后续理解：
-
/* 产品卡片价格 */→product-card__price已说清 -
/* 仅在侧边栏中生效 */→sidebar__item不依赖父容器，挪到.main下照样生效 -
/* 禁用时隐藏边框 */→input--disabled本身已表达状态，样式实现细节不该靠注释传递
但这些地方仍需注释：
立即学习“前端免费学习笔记（深入）”；
-
/* 为兼容 Safari flex gap，额外加 1px margin-top */—— 属于非直观视觉妥协 -
/* 与 JS 的 data-state="loading" 同步，避免样式/行为不一致 */—— 跨端联动逻辑 -
/* 注意：card--featured 必须配合 card__image 使用，否则布局错位 */—— Modifier隐含约束
Element命名是自解释能力的真正分水岭
写对Block名容易，写准Element名才是难点。一旦退化成user-card__delete-btn，就暴露两个问题：
- 带行为动词（
delete）→ 实际可能复用为“移除收藏”，语义窄化 - 带样式词（
btn）→ 如果某天换成Link组件，类名就失真
更健壮的写法是user-card__action--delete：Action是角色，delete是状态，二者解耦，可自由组合--edit、--share等其他Modifier。
第三方组件嵌套时，BEM自解释性不打折
直接覆盖.el-button类名会让自解释性归零——别人看到el-button--primary根本不知道它属于你哪个业务模块。正确做法是封装Wrapper：
<div class="my-form"> <el-button class="my-form__submit">提交</el-button> </div>
这样my-form__submit清晰表达“这是我表单里的提交按钮”，哪怕内部用的是Ant Design，语义归属依然明确。CSS里只写.my-form__submit相关规则，不碰.el-button原始类名。
真正难的不是记住__和--，而是每次写__element前都问一句：这个子内容是否真的属于当前Block的**不可再分的视觉组成部分**？如果不是，它大概率该是一个新Block。
