BEM不能解决z-index混乱，但能明确其归属与扩散范围；它将z-index绑定到具体Block（如.modal），依托position+堆叠上下文规则生效，并通过CSS变量统一管理值源，避免跨组件污染。
不能靠BEM解决z-index混乱，但BEM能帮你管住z-index的归属和扩散范围。 BEM本身不控制层叠顺序，它只负责把样式“圈进组件里”，避免z-index写在全局或跨组件污染。真正生效的还是position + z-index + 堆叠上下文规则——BEM只是让这套规则更容易落地、可追溯、不打架。
为什么BEM对z-index管理有实际帮助
BEM强制你把每个z-index绑定到明确的Block（比如.modal、.dropdown），而不是散落在.header .nav .item这种嵌套选择器里。这带来三个关键好处：
- 新增一个
.tooltip组件时，你自然会想到“它该在哪一层？是不是要复用--z-tooltip变量？”，而不是随手写z-index: 999 - 当
.modal__overlay和.modal__content需要分层时，它们同属.modalBlock，天然处于同一堆叠上下文内，z-index比较有效 - 别人改代码时，看到
.dropdown__menu就明白这是下拉菜单的子元素，不会误给.card__header也加z-index: 1000去“抢高度”
如何在BEM结构中安全使用z-index
关键不是“怎么写类名”，而是“z-index写在哪、值从哪来、谁有权改”。推荐做法：
- 所有z-index值必须来自单一源：CSS自定义属性（如
:root { --z-modal: 1050; --z-dropdown: 950; }）或预处理器变量（Sass/LESS） - Block根元素（如
.modal）负责设置基础z-index，子Element（如.modal__overlay）只用相对偏移（z-index: -1）或固定差值（z-index: calc(var(--z-modal) - 1)） - 禁止在Modifier类（如
.modal--fullscreen）里覆盖z-index——它只该改颜色、尺寸等视觉属性，层级属于Block职责 - 如果某个Element需临时提升（比如
.dropdown__item--active要浮在其他item上），优先用position: relative+z-index: 1（不脱离上下文），而非硬设全局高值
BEM + z-index常见翻车点
即使用了BEM，这些地方仍会悄悄破坏层级逻辑：
-
.modal自己没设position: relative或fixed，却给.modal__content写了z-index: 1050→ 完全无效，因为z-index只对定位元素生效 -
.dropdown父容器加了transform: translateY(0)，导致.dropdown__menu再高的z-index也出不去这个新堆叠上下文 - 多个Block（如
.modal和.sidebar）都用了--z-modal变量，但.sidebar意外设置了opacity: 0.99→ 它创建了独立上下文，.modal再高也盖不住它 - 在
里写.modal { z-index: var(--z-modal); }，但--z-modal没在:root声明 → 变量未定义，计算值回退为auto
最易被忽略的其实是“堆叠上下文边界”——BEM能让你快速定位是哪个Block在作祟，但最终得靠DevTools的Layers面板确认它是否真的被隔离了。写对类名只是第一步，看懂渲染树才是关键。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
