直接查Computed面板的Containing block和stacking context字段：absolute元素飞左上角是因未找到非static定位祖先，全为static时默认相对viewport；z-index失效主因是父级触发stacking context（如opacity<1、transform非none）或元素未定位。
直接看 Computed 面板里的 Containing block 和 stacking context 字段，比瞎调 z-index 有效十倍。
查 absolute 元素为啥飞到左上角
这不是 top/left 写错了，是它根本没找到定位参考系。position: absolute 会向上找最近的非 static 定位祖先——如果所有父级都是 position: static（默认值），那它就直接相对于 viewport 定位。
- 在 Elements 面板选中该元素 → 切到 Computed 面板 → 搜索
Containing block，看它实际绑定的是哪个节点 - 逐级点开父节点，在 Styles 面板确认是否有
position: relative、absolute或fixed - 临时给预期父容器加
position: relative（不带 top/left 也行），立刻验证是否回归预期位置 - 注意：某些 display 类型（如
display: flex）或transform会隐式创建包含块，但不改变 position 值，容易漏判
查 z-index 为啥不生效
z-index 只对已定位元素（position: relative/absolute/fixed/sticky）起作用；更常见的是被父级悄悄创建了新的 stacking context，把子元素的 z-index 锁死在局部。
- Computed 面板搜索
stacking context，标为 “Yes” 的节点就是新上下文起点 - 重点检查父级是否用了
opacity: 0.99、transform（哪怕只是translateZ(0)）、filter、will-change—— 这些都会触发 stacking context - iOS Safari 中，
transform+z-index组合尤其脆弱：必须同时加position: relative和z-index: 0，不能只靠transform: translateZ(0) - 真机测试不可跳过，模拟器常无法复现 stacking context 相关渲染异常
用 Layers 面板看图层分裂是否导致遮挡
Layer 面板不显示 stacking context，但它能暴露“物理层级”错位：两个元素即使 z-index 差 1000，若被分到不同合成层且图层顺序反了，照样被盖住。
立即学习“前端免费学习笔记（深入）”；
- 按
Cmd+Shift+P（Mac）或Ctrl+Shift+P（Win）→ 输入Layers→ 打开 Layers 标签页 - 刷新页面后，观察目标元素是否在独立图层里；若不在，检查是否缺
transform: translateZ(0)或will-change: transform - 右侧 3D 视图中，拖动视角看图层堆叠顺序；点击图层可高亮对应 DOM 节点
- 留意 “Overlapping layers” 红色警告——多个图层重叠区域易引发意料外的绘制顺序和性能问题
别忽略 HTML 结构本身是否被浏览器修正过
标签没闭合、嵌套错乱时，浏览器会自动“修复”DOM，结果可能是你写的父容器根本不存在，absolute 元素自然找不到参考系，z-index 关系也全乱套。
- 右键疑似父容器 →
Edit as HTML→ 删一行再回车，如果布局突变，说明原始结构已被修正 - 在 Console 执行
document.body.innerHTML，对比源码，多出来的</div>或消失的节点就是线索 - VS Code 装
Auto Close Tag插件，写<section>时立刻看有没有配对高亮，比肉眼扫快得多 - 老项目批量扫结构问题：用命令
tidy -e -q index.html报告未闭合标签精确位置
真正卡住人的，往往不是 z-index 数值不够大，而是某一层父容器默默加了 opacity: 0.99 或 will-change: transform，既不报错也不高亮，却让整个子树的层级逻辑失效。先查 stacking context，再动 z-index。
