overflow: hidden让absolute元素“消失”不是bug，是浏览器按规范裁剪：absolute元素以最近已定位祖先为包含块，若该祖先同时设overflow: hidden/auto/scroll，则超出其border box的部分被视觉切掉。
为什么overflow: hidden会让absolute元素“消失”
它不是bug，是浏览器按规范执行的裁剪行为。position: absolute元素的定位参考是最近的已定位祖先（即设置了position: relative/absolute/fixed/sticky的祖先），而这个祖先只要同时设置了overflow: hidden、overflow: auto或overflow: scroll，就会成为它的「包含块」和「裁剪边界」——超出该祖先内边框(border box)的部分，直接被视觉切掉。
常见误判点：
- 只检查直接父级，漏掉爷爷级甚至body上设的overflow: hidden
- Flex/Grid容器没加position: relative，却以为它能当包含块；其实它默认不创建定位上下文，但一旦加了overflow: hidden，又没设position，裁剪可能失效或错位
- 第三方组件（如Ant Design弹窗、轮播图）内部悄悄加了transform: translateZ(0)，意外创建新包含块，让absolute退化为相对它定位
用开发者工具选中元素后，按住Shift连续点右上角箭头，逐层看Computed里的overflow和position值，比调z-index快十倍。
怎么快速定位是哪个overflow在作怪
临时删掉可疑节点的overflow声明，看元素是否立刻“回来”。恢复了，就定位准了。
重点关注这些高频藏雷区：
-
.modal-wrapper、.carousel-container、Tab切换根节点 - 卡片外层、折叠面板容器、甚至全局
body上的overflow: hidden - 有固定高度（如
height: 400px）且内容未溢出的容器——此时sticky会被禁用，absolute也可能被裁剪
特别注意：transform、filter、opacity: 0.99、will-change: transform这些属性，哪怕没写overflow，也会让父级悄悄变成裁剪边界。在Computed面板里搜transform、filter、opacity，值不是none或1就要警惕。
不改DOM结构，还能怎么绕过裁剪
如果不能动HTML结构，这几个方案按可控性排序：
- 给裁剪容器加
display: flow-root（现代浏览器），让它形成BFC而不依赖overflow: hidden清浮动 - 把overflow: hidden拆出来：用一个内层
<div class="content">包住需裁剪的内容，让定位元素挂在外层容器上<li>用<code>clip-path: inset(0)替代overflow: hidden：它只做视觉裁剪，不建新包含块，不影响absolute和fixed，但Safari对inset()支持不稳定 - 改用
overflow: clip（Chrome 119+、Firefox 111+支持），语义更准，也不隐式创建层叠上下文，但Safari和旧版Firefox不认 - React：用
ReactDOM.createPortal挂到document.body下，再用getBoundingClientRect()动态算top/left - Vue：在
mounted钩子里调用document.body.appendChild(el)，或用<teleport to="body"></teleport> - 原生HTML：手动把元素挪到
底部，然后改样式选择器——别用.modal .fixed-btn这种依赖结构的写法，换成独立类名如.global-fixed-btn
别碰transform: translateZ(0)强行重绘——它可能临时让元素出现，但会破坏滚动性能，还可能让其他动画异常。
必须移DOM时，React/Vue/原生JS怎么操作
这是最稳的解法，尤其适合Tooltip、下拉菜单、浮层类场景：
移出去后务必检查是否还有transform/filter父级干扰：就算DOM在body下，如果body或html上加了transform: scale(1)，fixed仍可能退化。
移动端真机测试比模拟器关键：iOS软键盘弹出、横竖屏切换、页面缩放三者叠加时，fixed最容易失效，这不是CSS写错了，是渲染策略问题。这时候position: sticky反而更稳。
