同级absolute元素未设z-index时，默认按DOM顺序堆叠，后出现的覆盖前面的；z-index相等时同样遵循该规则；层叠上下文和定位基准会影响实际层级表现。
同级 position: absolute 元素的默认堆叠顺序由 DOM 顺序决定
没设 z-index 的两个同级 position: absolute 元素，谁在 HTML 中写在后面，谁就盖在上面。这不是“样式后加载覆盖”，而是 CSS 层叠规则明确规定的：z-index: auto 的元素不参与层叠比较，只按源码顺序排。
常见错误现象：
- 明明样式文件里先写了
.tooltip，但.dropdown还是把它盖住了——其实 HTML 中.dropdown在它后面 - 用 JS 动态插入的 absolute 元素总出现在最上层，因为它是最后 append 到 body 的
z-index 值相等时，DOM 顺序仍起作用
即使都写了 z-index: 10，只要值完全一样，后出现的元素依然会覆盖前面的。这和 CSS 选择器优先级无关，是层叠上下文内部的排序规则。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖“写在后面就一定在上”，尤其在组件化开发中，DOM 插入顺序不可控
- 若需稳定层级，必须让
z-index值有差异，哪怕只差1 - 避免把多个功能模块都设成
z-index: 999，后期加个弹窗就容易冲突
你以为同级，其实不在同一层叠上下文里
两个元素看似都直接挂在 <body> 下，但如果其中一方的某个祖先（比如 <header> 或 <app>）加了 transform: translateZ(0)、opacity: 0.99 或 filter: blur(1px)，就会悄悄创建新层叠上下文——子元素的 z-index 只在这个“结界”里有效，根本没法跟外面的元素比高低。
验证方式：
- Chrome DevTools 选中目标元素 → «Computed» 面板搜
stacking context，显示Yes就说明它或其祖先已触发 - 临时删掉父容器的
transform或opacity，看遮挡是否消失 - 别只盯着子元素调
z-index，得往上查两层父节点有没有“隐形结界”
父容器没设 position: relative 导致定位基准错乱
如果两个 absolute 元素的父容器都没设 position: relative，它们的定位原点可能都跑到 <body> 甚至视口去了。表面看是“互相覆盖”，实际是坐标系错位导致重叠区域意外重合——比如一个 top: 0 left: 0 盖住了导航栏，另一个 top: 0 left: 0 却飘到页面左上角空白处。
关键点：
- absolute 元素不是相对于父元素定位，而是相对于「最近已定位祖先」
- 没设
position: relative的父容器，等于不存在；浏览器会一路往上找，直到<body> - 想让覆盖层精准对齐目标元素？必须确保它们共享同一个定位容器（比如共用一个
position: relative的 wrapper）
真正难处理的从来不是 z-index 数字本身，而是层叠上下文的嵌套深度和定位基准的隐式迁移——改一个 transform 或补一行 position: relative，往往比调十次 z-index 更管用。
