fixed定位未失效，而是因祖先元素transform等属性创建新包含块，导致基准从视口降级为该祖先；需用DevTools逐层检查computed值验证并移除干扰或用Portal挂载到body。
它没失效，只是定位基准从视口变成了那个带 transform 的父级——这是 CSS 规范强制行为，不是 bug，也不是浏览器兼容问题。
为什么 fixed 会“变成 relative to parent”
只要任意祖先元素的 transform 计算值不为 none（比如 translateZ(0)、scale(1)、rotate(0)），它就创建了一个新的包含块（containing block）。此时子元素的 position: fixed 自动降级为相对于该祖先定位，视觉上等同于 position: absolute。
这不是渲染异常，而是 W3C 明确规定的定位上下文变更逻辑。你写的样式没变，但“锚点”已经换了。
-
transform: translateZ(0)是最常见陷阱——无视觉变化，但已生效 -
filter: blur(0)、opacity: 0.99、backdrop-filter: blur(1px)同样触发 - iOS Safari 还额外认
overflow-scrolling: touch，也会创建新包含块
怎么快速定位是哪个父级在“搞破坏”
别靠猜，用 Chrome DevTools 的 Computed 面板逐层验证：
立即学习“前端免费学习笔记（深入）”；
- 选中失效的
fixed元素 → 按住 Shift 连续点击右上角箭头，逐层跳转父节点 - 每到一层，切到 Computed 标签页，搜索
transform、filter、opacity、backdrop-filter - 重点盯
transform: translateZ(0)和第三方组件内部默认加的transform: translateX()（如 Ant Design 的Drawer、Element Plus 的el-dialog）
真正能上线的修复方式只有两种
临时加 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 是兜底方案，但滚动抖动、软键盘弹出时坐标错乱、性能开销大——只在极特殊场景考虑。
最容易被忽略的是：真机测试时缩放 + 横屏 + 软键盘三者叠加，问题才完全暴露；而很多第三方 UI 库的 transform 是静默注入的，DOM 结构里根本看不到。
