fixed元素被裁剪是因祖先元素创建新包含块，非overflow问题；需用DevTools逐层检查transform/filter/opacity等属性，修复方式为移至body下或改用sticky。
fixed 元素本就不该被父级裁剪——如果它被裁了，说明你遇到的不是样式没写对，而是浏览器按规范“主动干预”了它的定位行为。
为什么 fixed 元素会被父级裁剪？
这不是 overflow: hidden 的问题，而是父级（或更上层祖先）悄悄创建了新的 containing block。只要任意祖先元素满足以下任一条件，position: fixed 就会退化为相对该祖先定位，效果等同于 position: absolute：
-
transform计算值不为none（包括translateZ(0)、scale(1)等“无感”写法） -
filter不为none（哪怕只是blur(0)） -
opacity小于1 -
backdrop-filter、will-change: transform、perspective - iOS Safari 中的
overflow-scrolling: touch
此时它就真·受父容器 overflow: hidden 影响了——不是 bug，是 CSS 规范强制行为。
如何快速定位是哪个父级在破坏 fixed？
别靠猜，用 Chrome DevTools 直接查 computed 值：
立即学习“前端免费学习笔记（深入）”；
- 选中那个“不听话”的
fixed元素 - 按住 Shift 连续点击右上角箭头，逐层向上跳转祖先节点
- 每到一层，切到 Computed 面板，搜索
transform、filter、opacity - 重点盯
translateZ(0)、scale(1)、blur(0)这类值——视觉无变化，但已生效
第三方组件库（如 Ant Design 的 Drawer、Element Plus 的 el-dialog）常默认加 transform: translateX()，你没写，但它写了。
真正稳的修复方式只有两种
临时加 transform: none !important 能验证问题，但不能上线。生产环境必须选其一：
- 把元素移出干扰 DOM 树：React 用
createPortal挂到document.body；Vue 用Teleport或mounted中document.body.appendChild(el)；纯 HTML 就手动剪切到<body>底部 - 改用
position: sticky替代：比如top: 0，前提是父容器有明确滚动边界（如max-height: 600px; overflow-y: auto），且该父容器自身不带transform或opacity
慎用 JS 监听 scroll 手动算 top/left：软键盘弹出时视口高度突变，坐标直接错乱；节流不到位还会抖动；性能开销大，只在 DOM 结构完全锁死时兜底。
最常被忽略的是：移动端真机测试时，缩放 + 横屏 + 软键盘三者叠加，fixed 才彻底暴露问题；模拟器几乎不触发。iOS Safari 对 overflow-scrolling: touch 的处理也属于同一类规范行为，不是 bug，但容易漏查。
