position: fixed 相对于父元素定位不是 bug，而是 css 规范明确行为：当祖先元素设置了 transform（含 translatez(0)）、filter、perspective、opacity＜1 或 will-change 等属性时，会创建新 containing block，使 fixed 元素降级为相对该祖先定位。
为什么position: fixed会相对于父元素定位
这不是 bug，是 CSS 规范明确行为：transform（含 translate、scale、rotate、translateZ(0)）、filter、perspective、opacity 小于 1、will-change 等属性，只要值不为 none，就会让父容器创建新的 containing block。此时子元素的 position: fixed 就不再参考视口，而是参考这个新块——看起来就像“被父元素吸住”了。
常见错误现象包括：
-
fixed导航栏随页面滚动而移动 - 模态框
.modal出现在父容器右下角而非屏幕中央 - 用 DevTools 检查时发现元素被“卡”在某个
.wrapper或.grid-item内部，top/left值生效但基准变了
怎么快速定位是不是transform惹的祸
打开浏览器 DevTools，选中那个“不听话”的 fixed 元素，往上看它的所有祖先节点，逐层检查 computed 样式或 styles 面板里的以下属性：
-
transform是否为非none（尤其警惕translateZ(0)、scale(1)这类“无感”写法） -
filter是否存在（哪怕只是filter: blur(0)） -
perspective是否被设置 -
opacity是否 -
will-change是否包含transform或scroll-position
一旦发现某层祖先有上述任一属性，基本就是它导致 fixed 降级为 relative-to-parent 定位。
修复方案：优先移除，其次挪结构
最干净、兼容性最好、无需 JS 的解法永远是：移除不必要的触发属性。如果必须保留（比如为了硬件加速或动画），再考虑其他路径：
- 直接删掉父元素的
transform: translateZ(0)—— 大多数场景下它毫无必要，纯属过时优化惯性 - 把
fixed元素从嵌套结构里提出来，挂到下（例如把<div class="modal"> 移到 <code>前） - 避免用
position: absolute+ JS 动态计算位置来“模拟” fixed，这会引入 scroll、resize、orientationchange 等大量监听开销，且 iOS 键盘弹出时极易错位 - iOS Safari 软键盘弹出时，视口高度（
vh）重算，top: 0可能变成“贴着键盘顶部”，而非屏幕顶部 - 微信 X5 内核（尤其旧版）中，
input聚焦后fixed元素会被顶起，且不会自动回落 -
-webkit-overflow-scrolling: touch在某些安卓 WebView 中会让fixed在可滚动容器内完全失效
注意：不要试图给父容器加 contain: layout paint 来“修复”，它对 containing block 的创建无影响。
移动端特别注意：iOS Safari 和微信 X5 内核的双重陷阱
即使 DOM 结构和 CSS 都正确，fixed 在移动端仍可能失效或偏移：
这些不是 transform 引起的，但常被误判为同一类问题。真要兜底，只能用 focusin/focusout 临时切 position: absolute，并手动同步 top 值——但这属于防御性补丁，不是根本解法。
真正难缠的点在于：同一个 CSS 规则，在 PC Chrome 里完美，在 iOS Safari 里偏移，在微信里消失——问题根源未必是代码写错了，而是你没意识到，fixed 的“固定”本身，就依赖一整套脆弱的浏览器视口模型和渲染链路。
