z-index仅对position为relative、absolute、fixed或sticky的定位元素生效；其效果受限于层叠上下文，不同上下文间z-index数值不可直接比较，且移动端safari存在兼容性问题。
z-index 只对定位元素生效
很多人给元素设了 z-index 却没效果，根本原因是它只作用于「已定位」的元素——也就是 position 值为 relative、absolute、fixed 或 sticky 的元素。默认 static 的元素哪怕 z-index 设成 9999 也完全无效。
常见错误现象：div 盖不住 img，或者弹窗被导航栏切掉一半，大概率是其中一个没加 position: relative（哪怕只是占位用）。
- 最稳妥做法：需要参与层叠控制的元素，统一加上
position: relative，再设z-index - 不要依赖父容器的定位来“继承”层级——子元素的
z-index是相对于其最近的「定位祖先」计算的，不是全局 -
position: sticky在某些老版本 Safari 中对z-index支持不稳定，生产环境建议降级为relative+ JS 滚动监听
z-index 不是绝对数值，而是层叠上下文内的相对顺序
z-index 的实际效果取决于它所处的「层叠上下文（stacking context）」。一个新层叠上下文一旦创建，内部所有元素的 z-index 都只在这个上下文里比大小，不会和外部直接比。
触发层叠上下文的常见条件包括：opacity 小于 1、transform 不为 none、filter 存在、will-change 指定相关属性，当然还有 z-index 不为 auto 且父元素已定位。
- 典型踩坑：给弹窗父容器加了
transform: translateZ(0)做硬件加速，结果弹窗被挡在下面——因为这无意中创建了新层叠上下文，把弹窗锁死在局部层级里 - 调试技巧：Chrome DevTools 的「Layers」面板能直观看到层叠上下文边界；也可以临时删掉疑似触发的 CSS 属性来验证
- 如果必须用
transform又要保证层级穿透，改用translate3d(0, 0, 0)并确保父级不产生新上下文，或把弹窗挂到body下（脱离原上下文）
z-index 数值比较只在同层叠上下文中有效
两个不同层叠上下文里的元素，即使一个 z-index: 9999，另一个 z-index: -9999，谁在上谁在下，由它们各自所在上下文的「在父级中的绘制顺序」决定，而不是数字大小。
比如：A 容器（z-index: 1）里有个子元素 z-index: 9999；B 容器（z-index: 2）里有个子元素 z-index: -1。最终 B 容器整体盖在 A 上面，里面那个 -1 的元素依然盖过 A 里那个 9999 的元素。
- 避免跨上下文硬比数字：不要指望「只要我 z-index 够大就一定能盖住一切」
- 组件化开发时，建议约定基础层级范围（如：header=100, modal=1000, toast=2000），并确保每个组件根节点处于同一层叠上下文层级
- 动态插入的浮层（如 Tooltip），推荐用
createPortal（React）或直接document.body.appendChild（原生），从根源上避开父级上下文干扰
移动端 Safari 的 z-index 渲染异常
iOS 15+ 之前，Safari 对 z-index 的解析有多个已知缺陷：固定定位元素在页面滚动时偶尔闪现底层内容；input 获焦唤起软键盘后，部分 z-index 较高的元素会被强制压到键盘下方；使用 backface-visibility: hidden 触发的上下文有时层级计算错乱。
- 关键兼容策略：对关键浮层（如 Picker、ActionSheet），额外加
transform: translateZ(0)+will-change: transform强制创建独立上下文并提升渲染优先级 - 不要依赖
z-index控制软键盘与界面的遮挡关系——iOS 会重排输入框上方空间，此时应靠scrollIntoView或focus事件回调做位置微调 - 真机测试不可跳过：模拟器无法复现多数 Safari 层级 bug，必须在 iOS 实机上滚动、缩放、唤起键盘多轮验证
层级问题从来不是单个 z-index 能解决的，它背后是定位模型、层叠上下文、渲染管线三者的耦合。最常被忽略的，是以为改个数字就行，却没检查 position 是否到位、上下文是否意外隔离、移动端是否悄悄重写了规则。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
