overflow: hidden 截断 absolute 元素的根本原因是包含块（非 static 定位祖先）同时触发裁剪边界，需逐级检查 position 与 overflow 计算值，优先用 Portal 或 BFC 方案解耦。
不是加个 overflow: visible 就能解决，关键得看谁在裁、为什么裁、裁的是不是你真想裁的部分。
为什么 overflow: hidden 会截断 position: absolute 元素
裁剪行为不来自“父元素”这个视觉关系，而来自「包含块（containing block）」和「裁剪边界」的双重绑定：
- 只要某个祖先元素
position不是static（比如relative、absolute），它就可能成为绝对定位元素的包含块 - 如果这个包含块同时设置了
overflow: hidden（或auto/scroll且内容溢出），浏览器就会以它的内边框为界裁剪所有后代——包括脱离文档流的absolute子元素 -
z-index完全无效：裁剪发生在绘制前，层级再高也出不来
检查哪一层在偷偷裁你
别只盯着直接父元素。用 DevTools 逐级向上点开 parentElement，直到 body，重点看：
- 哪些层的
computed position是relative/absolute/fixed/sticky - 这些层中，哪些同时有
computed overflow为hidden、auto或scroll - 临时删掉可疑层的
overflow声明（或改成visible），观察目标元素是否立刻显示完整
常见藏匿位置：.modal-wrapper、.card 根节点、Tab 切换容器、Swiper 外壳、CSS-in-JS 注入的全局样式。
立即学习“前端免费学习笔记（深入）”；
改 overflow 不等于解决问题
直接把 overflow: hidden 改成 visible 往往只是暴露了更深层的问题：
- 如果该容器本就需要隐藏溢出（比如轮播图圆角裁剪、卡片内容封边），
visible会让其他内容穿帮 - 如果容器高度塌陷（内部只有
absolute子元素），overflow: hidden本身就没作用对象，改了也没用 -
transform、opacity、will-change等属性会创建新层叠上下文，让overflow行为更难预测 -
overflow: clip（Chrome 119+）语义更准，但 Safari / Firefox 兼容性差，不能当主力方案
真正可用的实操路径
按可控性和副作用排序：
- 把要“破框”的元素（如 Tooltip、下拉菜单）用
ReactDOM.createPortal或document.body.appendChild()移到body下，再用 JS 动态计算top/left位置 - 保留 DOM 结构，但给裁剪容器加
display: flow-root（现代浏览器）或zoom: 1（IE），让它形成 BFC 而不依赖overflow: hidden清浮动 - 把
overflow: hidden拆出来：用一个内层<div class="content"> 包住需裁剪的内容，让定位元素挂在外层容器上 <li>用 <code>clip-path: inset(0)替代overflow: hidden——它裁视觉，不建包含块，不影响absolute和fixed元素，但 Safari 对inset()支持不稳定
最常被忽略的一点：哪怕只是加了 transform: translateZ(0)，也会让父容器变成包含块+层叠上下文双锁定，此时光调 overflow 已经不够用了。
