overflow: auto 会裁剪绝对定位子元素且创建层叠上下文，导致 z-index 失效；需检查 position 和 stacking context，优先用 overflow: visible 或将弹出元素移至 body 下。
overflow: auto 会裁剪绝对定位子元素，和 z-index 无关
overflow: auto（或 hidden/scroll）本身不改变 z-index 的计算逻辑，但它会强制创建一个**裁剪边界（clipping boundary）**，任何超出该容器可视区域的 position: absolute 或 fixed 子元素，都会被直接切掉——z-index 根本没机会参与绘制。你调再大的 z-index 都没用，因为内容在“画之前”就被砍了。
常见错误现象：dropdown 下拉菜单被父容器截断、tooltip 只显示一半、modal 在滚动容器里消失。
- 检查父容器是否真需要
overflow: auto：很多场景只是为了“清除浮动”，其实应改用display: flow-root或伪元素::after - 如果必须保留滚动能力，又需弹出内容完整显示，把定位元素移出该容器 DOM，挂到
<body>下，再用 JS 动态同步位置 - Chrome 119+ 支持
overflow: clip，语义更清晰，但 Safari / Firefox 尚未支持，不能替代方案
overflow: auto 会隐式创建层叠上下文，锁死 z-index 范围
只要父容器设置了 overflow: auto（或 hidden/scroll），且自身是已定位元素（比如 position: relative），它就会成为一个独立的层叠上下文（stacking context）。此时子元素的 z-index 只跟这个容器内部比高低，无法穿透出去和页面其他区域竞争。
典型表现：一个 z-index: 9999 的下拉菜单，被同页面另一个 z-index: 1 的 header 盖住——因为 header 在根层叠上下文，而菜单被锁在父容器的子上下文中。
立即学习“前端免费学习笔记（深入）”；
- 用 Chrome DevTools 的 «Layers» 面板可直接看到哪些节点建立了 stacking context
- 临时删掉父容器的
overflow和position，看遮挡是否消失；若消失，就坐实是上下文隔离问题 - 避免“只调子元素
z-index”：得把整个功能模块（包括它的父容器）一起提升层级，比如给父容器也设position: relative和合理z-index
为什么 overflow: visible 就没事？
overflow: visible 是唯一不触发裁剪也不强制创建新层叠上下文的值（除非配合其他属性如 transform）。它允许子元素自由溢出，z-index 在预期范围内正常工作。
但要注意：如果父容器没设 position，子元素用 absolute 时会以最近的已定位祖先为参考——可能意外参照到 <body>，导致定位错位。
- 安全做法：需要弹出内容的容器，显式加
position: relative，同时保持overflow: visible - 不要依赖默认
overflow值：某些 CSS 重置库（如 Normalize.css）会把overflow设为visible，但自定义组件中常被覆盖 - 移动端尤其敏感：iOS Safari 对
overflow: auto+position: fixed组合有渲染 bug，可能出现闪退或错位
z-index 没反应？先查 computed position 和 stacking context
浏览器根本不读 z-index 的两种最常见情况：目标元素 position 最终是 static，或者它被某个祖先的层叠上下文“关进去了”。overflow: auto 往往是那个“关门”的人，但它不声不响。
打开 Chrome DevTools → 选中被遮挡元素 → «Computed» 面板搜索 position 和 z-index：
- 如果
position显示static，说明你漏写了position: relative等声明 - 如果
z-index显示auto，说明它没激活层叠计算流程 - 搜索
stacking context，看哪一级祖先写着 “This element establishes a stacking context”
真正棘手的不是数值大小，而是你根本不知道自己正在哪个“房间”里比大小。
