根本原因是transform父元素创建新包含块，使fixed退化为相对其定位：只要祖先元素transform计算值非none（如translateZ(0)）、filter或opacity<1，就会强制fixed锚定该祖先而非视口，这是CSS规范强制行为。
transform 会让 fixed 元素变成 relative 定位的参照物
根本原因：只要父元素设置了 transform（哪怕只是 transform: translateZ(0)），它就会创建一个新的「层叠上下文」和「包含块（containing block）」，导致内部的 position: fixed 元素不再相对于视口定位，而是相对于这个 transform 父容器定位——这在视觉上就表现为“fixed 失效”或“位置飘移”。
这不是 bug，是 CSS 规范明确规定的：当一个元素具有 transform、filter、will-change 等属性时，它会成为其子元素中 position: fixed 的包含块。
- 常见触发场景：
transform: translateX(10px)、transform: scale(1)、甚至transform: none（某些旧版 Safari 中也触发） - 即使 transform 值“没效果”，只要声明了，就创建包含块
- Chrome/Firefox/Safari 均遵守该行为，无兼容性差异
怎么快速验证是不是 transform 导致的？
打开 DevTools，逐级检查 fixed 元素的祖先节点，看是否有任意一层设置了 transform、filter 或 will-change。特别注意那些“看起来没用”的样式，比如：
.container {
transform: translateZ(0); /* 常见性能优化写法，但会破坏 fixed */
will-change: transform;
}临时删掉这些声明，观察 fixed 元素是否立刻回到视口基准定位——如果恢复了，就是它。
立即学习“前端免费学习笔记（深入）”；
- 不要只查
transform，filter: opacity(0.99)同样有相同效果 - Vue/React 组件中，可能由动画库（如 framer-motion）或 UI 框架自动注入，需 inspect computed styles
- 移动端 Safari 对
transform: scale(1)更敏感，有时仅在真机复现
绕过 transform 影响 fixed 定位的实用方案
不能简单删掉 transform（比如为了开启硬件加速或实现动画），得换结构或换策略：
- 把
position: fixed元素移到 transform 父级之外，比如挂到<body>下，用 JS 同步位置（适合弹窗、Tooltip 等） - 用
position: sticky替代（如果只需视口内吸附，且容器有滚动流） - 放弃
fixed，改用position: absolute+ 动态监听window.scrollY更新top（慎用，重绘开销大） - 对 transform 父级加
contain: layout paint（不推荐：部分浏览器不支持，且不能阻止包含块变更）
最稳妥的做法仍是「结构隔离」：让 fixed 元素脱离 transform 树。CSS 本身不提供“忽略父级包含块”的开关，这是设计限制，不是配置疏漏。
为什么加了 transform 就要变包含块？
因为 transform 强制元素进入独立图层（layer），渲染引擎需要重新定义其子元素的定位参考系。fixed 的语义是“相对于初始包含块（即视口）”，但一旦父级成了独立图层，它就无法再穿透该边界去绑定视口——否则会破坏图层合成逻辑和滚动性能。
这点在复杂滚动场景（如 iOS WebKit 的 overflow-scroll + transform 混用）中尤为明显：fixed 元素可能随父容器一起被缩放、裁剪，甚至消失。
- 不是所有 transform 都有问题：只有 applied transform（计算后非 identity）才一定触发；但为安全起见，应视为“只要写了就生效”
- 如果必须共存，优先考虑用 JS 控制定位，而非依赖纯 CSS fixed
真正容易被忽略的是：这个行为不会报错、没有 warning，只在布局错位时才暴露——而排查时往往先怀疑 z-index 或 margin，很少往 transform 上想。
