fixed在transform父元素中“变成absolute”是CSS规范强制行为：只要任意祖先transform计算值不为none（如translateZ(0)），就会创建新包含块，使fixed退化为相对该祖先定位；同效属性还包括filter、opacity<1、backdrop-filter、will-change及iOS Safari的overflow-scrolling: touch。
为什么fixed在transform父元素里会“变成absolute”
这不是浏览器bug，是CSS规范强制行为：只要任意祖先元素的transform计算值不为none（哪怕只是transform: translateZ(0)），它就会创建新的包含块（containing block），导致子级position: fixed自动退化为相对于该祖先定位——视觉效果等同于position: absolute。
同效属性还包括：filter（哪怕blur(0)）、opacity小于1、backdrop-filter、will-change: transform，甚至iOS Safari里overflow-scrolling: touch也会触发。
怎么快速定位是哪个父级在破坏fixed
别靠猜，用Chrome DevTools直接查computed值：
- 选中失效的
fixed元素，在Elements面板按住Shift连续点击右上角箭头，逐层跳转父节点 - 每到一层，切到Computed面板，搜索
transform，看值是否为none - 重点盯
translateZ(0)、scale(1)、rotate(0)这类“伪变换”写法——它们没视觉变化，但已生效 - 顺手搜
filter、opacity、backdrop-filter，它们有同等破坏力
真正有效的修复方式只有两种
临时加transform: none !important能验证问题，但不能上线。生产环境必须选以下之一：
立即学习“前端免费学习笔记（深入）”；
- 把
fixed元素从transform容器里拎出来，挂到<body>下：React用createPortal，Vue用Teleport，纯JS用document.body.append(el) - 保持DOM位置不变时，优先换
position: sticky：比如top: 0或bottom: 0，现代浏览器支持良好，且完全不受transform干扰 - 慎用
position: absolute+ JS监听scroll模拟fixed：滚动抖动、软键盘弹出时坐标错乱、性能开销大，只在极特殊场景兜底
最容易被忽略的隐形陷阱
第三方组件库内部悄悄加了transform——Ant Design的Drawer、Element Plus的el-dialog、某些轮播图组件，默认用了transform: translateX()或translateZ(0)，你写的fixed按钮只要嵌套在里面，立刻失效。
真机测试比模拟器关键：缩放 + 横屏 + 软键盘三者叠加时，问题才完全暴露；iOS Safari对overflow-scrolling: touch的处理也属于同一类规范行为，不是bug，但容易漏查。
