block名泛化导致跨组件样式污染最常被忽略的问题是把container、box、section等通用词当block名，应使用product-card、user-profile等业务语义化名称确保唯一性。
Block 名泛化导致跨组件样式污染
最常被忽略的问题是把 container、box、section 这类通用词当 Block 名。它们在项目里高频复用，结果 .box__title 在商品页、弹窗、侧边栏同时生效，改一处就崩三处。
真正有效的 Block 名必须来自具体业务模块：product-card、user-profile、notification-banner。这些名字天然不可重名，不是靠“起得生僻”，而是靠它对应一个真实可复用的功能单元。
常见错误现象：
- 目录是
/components/product-card/，但 CSS 里写成.card__title—— 失去路径与命名的映射，唯一性失效 - 所有弹窗都叫
modal，然后叠加modal--success和modal--error—— 实际上它们语义不同，应拆成confirm-modal、alert-modal - 用
active-tab当 Block 名 —— 它不是独立组件，只是 tab 的一种状态，应写作tab--active
Element 嵌套过深或跨 Block 复用
BEM 明确禁止 .block__element__subelement 这种写法。一旦出现三层结构，说明逻辑已经越界，要么该拆新 Block，要么命名本身错了。
比如 .card__content__title 是错的：title 是 card 的直接视觉子元素，应写作 card__title；而 .header__nav__link 更危险——nav 本就是独立功能模块，不该作为 header 的 element，正确做法是拆成两个 Block：header 和 nav，各自管理自己的 __link。
Element 不得跨 Block 复用：.button__icon 和 .card__icon 必须是两个独立类名。如果 icon 确实高频复用，它自己就该升为 Block：icon 或 badge。
Modifier 脱离主体或描述实现细节
修饰符必须绑定到明确的 Block 或 Element，不能孤立存在。写 is-active 或 btn--left 是典型破规 —— 前者没归属，后者依赖位置，在响应式下极易失效。
更隐蔽的坑是 modifier 描述实现而非状态：button--loading 暴露了 JS 加载逻辑，换主题时要全局搜替换；而 button--submit 或 button--primary 表达意图，可由主题系统统一控制。
还有常见断裂逻辑：card__title--dark 却没定义 card--dark —— 元素级 modifier 应依赖块级状态，否则样式上下文不完整。
SCSS 中尤其容易踩坑：&__content { &__icon { ... } } 会编译出后代选择器 .card__content .card__content__icon，破坏 BEM 封装性。只允许 &__icon 和 &--modifier 这两种单层嵌套。
动态拼接类名绕过 BEM 静态约束
React 里写 className={`card__header ${isSticky ? 'card__header--sticky' : ''}`} 看似无害，但维护成本高、易拼错、难做 lint 检查。更危险的是模板字符串构造：`${block}__${elem}--${mod}` —— 若 elem 来自 props 且含空格或特殊字符，类名直接失效。
正确做法是硬编码全称 + 工具函数组合：clsx('card__header', { 'card__header--sticky': isSticky })。所有 __ 和 -- 部分必须静态可预测，不能动态生成。
SSR 场景下这点尤为关键：服务端渲染出的类名若和客户端不一致（比如用了随机 ID），会触发 hydration mismatch。BEM 类名必须稳定、静态、可 grep。
实际项目中最难守住的不是语法，而是 Block 的边界感——它不是 HTML 结构的投影，而是业务语义的切片。一旦开始用div 层级代替 Block 划分，BEM 就退化成了带下划线的普通命名。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
