BEM类名过长源于组件边界不清，应将高频复用、有独立状态的子结构升格为新block，避免深层嵌套；状态宜提升至父block统一控制；命名优先功能而非位置，确保语义自包含。
为什么BEM类名一写就变“超长身份证号”
因为没控制好组件边界——把本该独立的视觉模块硬塞进一个组件里，block__element--modifier 层级自然往死里堆。比如 user-profile-card__header-avatar-wrapper--is-loading，这不是语义，是妥协。BEM本身不鼓励深嵌套，但人容易在“这个小图标肯定属于卡片”这种直觉下越写越长。
用block拆解代替__element叠加
把高频复用、有独立状态或样式边界的子结构，直接升格为新block。不是所有“内部东西”都得是__element。
- 原写法：
search-form__input-field--has-error+search-form__submit-button--disabled - 改写后：
form-field和button各自成块，search-form只负责布局容器和上下文关系（如search-form--compact） - 好处：避免
search-form__field-input--error这类四层命名；form-field可复用于登录表单、筛选栏等场景
警惕--modifier滥用：状态提升到父block更干净
当多个子元素共用同一状态（如“加载中”“禁用”），别给每个__element加--modifier，而是让父block承载状态语义。
- 反例：
dashboard__header--loading+dashboard__chart--loading+dashboard__list--loading - 正解：
dashboard--is-loading，再用 CSS 选择器批量控制子元素：.dashboard--is-loading .dashboard__header等 - 注意：需配合合理的 CSS 作用域（如用
:where()或scoped避免污染）
组件命名优先选“功能”而非“位置”
sidebar-nav-item 比 layout__sidebar-nav-item 更轻量，且不绑定布局层级。只要它自己能说清“我是导航项”，就不需要靠父级名字来背书。
立即学习“前端免费学习笔记（深入）”；
- 判断标准：把这个类名单独拿出来，别人能否猜出它的职责？
price-tag✔️，product-card__price-tag❌（后者暴露了它被谁包含） - 配套动作：用文件夹结构补足上下文，比如
/components/price-tag/下放独立样式和逻辑，而非全塞进product-card目录 - 例外：纯布局辅助类（如
grid-col-4）可保留中性命名，不强求语义
block维护——哪怕它只在一处用到。 
