绝对定位元素被父级 overflow: hidden 裁剪，是因为该父级是其包含块；若父级为 static 或非最近已定位祖先，则裁剪不生效；破框关键在于切断包含块关系，而非调 z-index。
绝对定位元素被父级 overflow: hidden 裁剪，不是它“不听话”，而是它确实被框住了——只要父级同时满足两个条件：是它的包含块（containing block），又设置了非 visible 的 overflow。想让它“破框而出”，核心是**切断它和该父级的包含块关系**，而不是调 z-index 或加动画。
为什么加了 overflow: hidden 还是不管用？
因为裁剪生效的前提，是父级必须是它的包含块。而包含块只由「最近的已定位祖先」提供——即 position 值为 relative、absolute、fixed 或 sticky 的祖先元素。如果父级仍是默认的 position: static，那子元素的包含块可能是上层某个 position: relative 的容器，甚至 body；此时你在“视觉父级”上设 overflow: hidden，等于在错误对象上操作。
常见现象：
- 父容器明明写了
overflow: hidden，但position: absolute的 tooltip 仍伸出边界 - DevTools 的 Computed 面板里，
containing block显示的是html或其他远祖节点
让绝对定位元素真正“逃出”的三种可靠方式
目标不是绕过裁剪，而是让那个带 overflow: hidden 的父级，**压根就不是它的包含块**：
立即学习“前端免费学习笔记（深入）”；
- 把父级的
position改回static（删掉position: relative等）——浏览器会继续向上找，直到找到下一个已定位祖先，或落到视口 - 给父级显式设
overflow: visible——这是唯一能覆盖裁剪行为的值，且不会触发新层叠上下文 - 把绝对定位元素从该父容器中移出，挂到
body下（现代框架可用Portal或Teleport）
注意：transform、filter、will-change 会隐式创建包含块，哪怕父级是 position: static，也可能意外把它框住。
Flex/Grid 容器里特别容易踩坑
即使父级是 position: static，只要它是 display: flex 或 display: grid，且设置了 overflow: hidden，它就**自动成为包含块**（CSS 规范明确列出）。这不是 bug，是设计如此。
修复方式只有两个：
- 把
overflow: hidden改成overflow: visible - 把绝对定位元素移出该 Flex/Grid 容器（DOM 搬运或 Portal）
别指望 z-index 解决——它只管层叠顺序，不解除裁剪边界。
移动端 fixed 元素无法被裁剪是渲染机制限制
position: fixed 的包含块永远是视口，不受任何父级 overflow 影响。所以你给一个 position: relative + overflow: hidden 的父容器套个 position: fixed 子元素，它照样溢出——这不是写错了，是 iOS Safari 和多数 WebView 的底层行为。
如果必须嵌套，只能退而求其次：
- 改用
position: absolute+top: calc(100vh - Xpx)模拟 fixed 效果 - 或者直接放弃嵌套，让 fixed 元素作为
body的直系子元素
真正卡住越界的点，往往不在子元素本身，而在你没意识到哪个祖先悄悄成了它的包含块——打开 DevTools，看一眼 Computed 里的 containing block，比调十次 z-index 更快定位问题。
