bem命名核心是复用性而非视觉切割，metric-card应作为独立block，元素必须两级扁平结构，修饰符仅表达状态或固定变体，所有拆分需满足“脱离父容器仍可复用”标准。
复杂卡片组件的BEM命名不是“怎么切更顺眼”，而是“拆完能不能挪到告警页、报表页、弹窗里还正常工作”。不能复用的拆分，就是错的。
把功能职责当唯一拆分依据，别按视觉区域切
常见错误是看到卡片顶部有标题+刷新按钮+下拉菜单，就写成 .card__header 里塞一堆没名分的 div；或者直接定义 .dashboard__metric-card——这等于把卡片和页面强绑死。
- 正确做法：独立出
metric-card这个 Block，它自带metric-card__header、metric-card__body、metric-card__footer - 如果卡片里嵌了可复用的列表（比如指标趋势项），别写
metric-card__body__list__item，直接提成独立 Block：list+list__item - 判断标准就一条：删掉父容器后，这个 UI 片段是否还能被其他模块原样引用？能，就是 Block；不能，它只是 Element
元素命名必须显式、扁平、不可嵌套
metric-card__header__action 或 card__cover__title-icon 这类三层命名是明确违反 BEM 的。浏览器不认，工具链难解析，人也容易看串。
- 所有 Element 必须是
block__element两级结构，中间双下划线，无空格、无连字符、无驼峰 - 图标、副标题、操作按钮都应平级声明：
metric-card__title、metric-card__subtitle、metric-card__header-action - 需要图标配合标题？用
metric-card__title-icon，不是metric-card__header__icon；真要复杂交互，就该抽成新 Block，比如status-badge
修饰符只表达状态或固定变体，不描述位置或上下文
写 card__button--in-header 或 metric-card__value--in-small-screen 是危险信号。这类修饰符一换场景就失效，还容易和全局样式冲突。
- Modifier 应聚焦业务语义或视觉契约：
metric-card--loading、price-display--pending、button--primary - 响应式行为不靠修饰符推导，而用显式断点修饰符（需构建工具支持）：
metric-card__footer--collapsed@sm，而非依赖媒体查询内联或 JS 切类 - 状态类（如
is-completed）和 Modifier 分开用：前者用于跨组件识别的运行时状态，后者用于预设的、静态的视觉变体
真正卡住人的从来不是命名规则本身，而是每次拆分前没问一句：“它离开这张卡片，还能不能活？”——答案是否定的，那就要继续往下拆，直到每个 Block 都能单独测试、上线、被别的页面拎走就用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
