类名失控本质是组件边界模糊，源于将页面容器当block、临时状态当modifier、共用结构硬塞父级，违背bem“block须独立可复用”初衷；三层下划线、修饰符堆叠、描述性短语、缩写类名、滥用modifier均暴露设计逻辑错位，而非命名规则本身问题。
类名失控本质是组件边界模糊，不是BEM规则太严
真正让类名难维护的，不是__和--本身，而是把页面容器当Block、把临时状态当Modifier、把共用结构硬塞进某个父级——比如写dashboard-page__user-card__avatar--size-lg--theme-dark，这已经违反BEM初衷：Block 应是独立可复用单元，不是HTML嵌套路径的转译。
- 三层下划线（如
header__nav__item__link）说明Element被错误地跨Block嵌套，应拆出nav-item作为独立Block - 修饰符堆叠（如
button--theme-primary--size-xl--variant-outline--is-loading）暴露的是配置逻辑错位，不是命名问题 - 所有Modifier必须离散、互斥、可枚举；禁止
--very-big-and-centered这类描述性短语，它无法被JS控制或CSS变量替代
缩写类名只会让DevTools调试变成猜谜游戏
把user-card__avatar--size-lg缩成uc-avt--l，表面省了字符，实际代价是：编辑器里搜uc-avt找不到上下文，PurgeCSS不敢删怕误伤，新人看代码得查文档才能知道这是用户头像。
- Gzip对重复前缀（如
user-card__）压缩效率极高，实测类名变长20%后压缩体积反而下降15%～25% - 构建工具（如Lightning CSS、PurgeCSS）依赖静态类名分析，缩写后字典匹配率暴跌，容易漏删或误删
- 浏览器DevTools里显示
uc-avt--l时，你无法一眼判断它属于哪个组件、是否复用、有无JS绑定
CSS自定义属性比Modifier更适合接管样式变量
当Modifier只控制颜色、圆角、间距等可变值时，硬编码类名就是重复劳动。用--button-padding代替button--size-xl，能让类名回归语义本质，且支持运行时注入。
- 变量必须由JS或构建时注入，不能靠人工维护多套CSS；例如：
el.style.setProperty('--btn-theme', 'primary') - 保留布尔型Modifier（如
button--disabled），但删掉枚举型（如--size-xl），尺寸改用工具类或CSS变量 - 禁止
button--theme-primary__icon这种写法——theme是按钮整体状态，不该挂到子元素上；应统一用button--primary，再由内部规则控制图标
小项目强行套完整BEM，等于给自行车装航空发动机
CSS文件≤3个、无跨路由复用、团队≤2人时，login-form__submit-button--primary这种写法不是规范，是负担。这时候该用BEM-Lite：允许card-title代替card__title，禁用三层嵌套，Modifier默认不启用。
- 纯展示结构（如
hero-section__title）可直接简化为hero-title，前提是无全局冲突风险 - 状态类交给JS控制通用开关，如
is-loading、has-error，不塞进某个Block下 - 判断是否需要BEM，只看一个标准：这个样式会不会被其他地方复用？如果答案是否定的，单class就够了
page__section__header__title，就该立刻停手——section和header早该是独立Block。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
