BEM选择器不应嵌套过深，须保持元素语义独立；修饰符专注静态外观，伪类统一处理；JS操作应解耦控制类名；响应式逻辑交由媒体查询或容器查询，而非混入BEM命名。
为什么 CSS 选择器不该嵌套过深，哪怕用了 BEM
BEM 命名本身就是为了减少选择器层级依赖，但很多人写 .header__nav .header__item:hover 这类带空格的后代选择器，等于绕过了 BEM 的初衷。浏览器匹配 CSS 是从右往左的，.header__item 虽然带了块（Block）前缀，但加上祖先限定后，实际仍触发了深度遍历，性能没改善，可维护性反而下降。
正确做法是让每个 BEM 元素（Element）具备语义独立性：
- 用
.header__item直接定义样式，不依赖父容器是否为.header - 状态修饰符走
.header__item--active，而不是.header__item.active - 若真需上下文差异（比如暗色模式下 header 导航不同），用属性选择器或顶层 class 控制：
[data-theme="dark"] .header__item，而非嵌套
如何处理 BEM 中的修饰符（Modifier）与伪类/伪元素共存
常见错误是把伪类和修饰符混写成 .btn--primary:hover，看起来没问题，但一旦需要复用 --primary 修饰符到其他组件（比如 .link--primary），就会被迫重复写 hover 样式，违背 DRY。
更可持续的方式是分离关注点：
立即学习“前端免费学习笔记（深入）”；
- 修饰符只负责「静态外观」：颜色、尺寸、圆角等可复用的视觉变量
- 伪类交由基础类或工具类接管：
.btn:hover统一定义悬停反馈（如阴影、过渡） - 如果某修饰符确实需要覆盖伪类行为（例如禁用态按钮不应有 hover 效果），用
.btn--disabled:hover显式覆盖，但仅限例外
这样既保住了 BEM 的可组合性，又避免样式逻辑散落在多个地方。
JavaScript 操作 BEM 类名时容易踩的坑
前端常通过 element.classList.add("modal__close--hidden") 控制显示隐藏，但问题在于：一旦 BEM 类名变长或结构微调（比如从 modal__close 改成 modal__trigger-close），JS 层就得同步改，耦合度高。
推荐两个实践：
- 约定「控制类名」与 BEM 类名解耦，例如统一用
is-hidden、is-open这类语义化工具类，CSS 里用.modal__close.is-hidden { display: none; }关联 - 如果必须操作 BEM 类，用正则或工具函数提取 Block 名，避免硬编码：
el.classList.toggle(`${getBlockName(el)}__item--selected`)，其中getBlockName()从el.className中解析出modal或card
媒体查询中 BEM 类名要不要加响应式修饰符
像 .card--sm-up 或 .card__content--mobile 这类命名看似清晰，实则制造了冗余维度：BEM 的 Element 本应描述“它是什么”，而不是“它在哪儿显示”。响应式逻辑应该由布局容器或 CSS 容器查询（@container）驱动，而非塞进类名。
更合理的方式：
- 保持 BEM 类名不变，用媒体查询包裹样式：
@media (max-width: 768px) { .card__content { padding: 8px; } } - 若组件需完全不同的结构（比如移动端折叠菜单），用 JS 切换根级修饰符：
<div class="nav nav--mobile"></div>，再配.nav--mobile .nav__item规则 - 避免出现
.btn--md-hover这种把尺寸 + 状态 + 媒体混在一起的类名，后期根本没法维护
BEM 是命名规范，不是响应式方案。把它当「字符串契约」来守，比当「功能开关」来用更可靠。
