position: fixed 在 ios 中“失效”实为被降级为 relative 或 absolute，主因是祖先元素触发新包含块（transform/filter/opacity）、滚动容器非 body、或键盘弹出导致视口错位，应移至 body 下、改用 sticky 或 absolute 动态计算 top。
position: fixed 在 iOS 中“失效”，不是写错了，而是它**根本没按你预期的方式工作**——它被浏览器悄悄降级成了 position: relative 或 position: absolute，视觉上就是“跟着滚动”“错位”“闪一下就消失”。
这背后没有玄学，只有三条硬规则在起作用。
祖先元素带 transform/filter/opacity 就会破坏 fixed 定位
只要任意父级（哪怕隔了 5 层）设置了以下任一属性，position: fixed 就立刻失去“相对于视口”的能力：
-
transform值不为none（包括translateZ(0)、scale(1)、rotate(0deg)） -
filter值不为none（哪怕只是blur(0)或拼错成fliter） -
opacity小于1（opacity: 0.999也触发）
这些属性会创建新的包含块（containing block），而 fixed 元素只能相对于「最近的定位上下文」定位——一旦祖先变成新包含块，它就不再锚定视口，而是锚定那个祖先。
滚动容器不是 fixed 会彻底失联
uni-app、Vue Router 页面、或手动设了 .content { overflow: auto } 的场景里，fixed 元素实际是相对于这个可滚动容器定位，而非整个屏幕。常见表现：
- 顶部导航栏在页面内滚动时“跟着动”
- 底部按钮在长列表里突然偏移几十像素
- 弹窗遮罩层只盖住局部区域，而不是全屏
这不是 bug，是 CSS 规范定义的行为：fixed 的“视口”取决于它的**最近滚动祖先**。如果滚动发生在某个 div 里，那它就只认那个 div 的尺寸和位置。
iOS 键盘弹出时 fixed 元素被顶飞或错位
iOS 不会把软键盘唤起当作“视口高度变化”，而是直接挤压 visualViewport，但旧版 Safari（）根本不响应这个事件。结果就是：
-
fixed元素仍按原始视口高度计算位置，被键盘顶到屏幕外 - 输入框聚焦后，
fixed按旧坐标渲染，出现明显跳变 - 某些 WebView（如微信、QQ 内核）甚至直接丢弃
fixed合成层，退化为重绘
监听 focus/blur 并临时切为 position: absolute + 手动算 top 是目前最稳的 fallback，但要注意：别用 window.visualViewport 做统一判断——Android Chrome 支持，iOS Safari 直到 16.4 才部分支持，且行为不一致。
真机测试最容易漏掉的三个干扰点
DevTools 模拟器几乎 100% 不复现问题，必须实测：
- 系统设置里开了「减少动画」会抑制 GPU 合成行为，导致
translateZ(0)等 hack 完全无效 - 微信、QQ、支付宝等壳浏览器用的是老版本 WebKit 内核（常卡在 iOS 14–15），比系统 Safari 更容易退化
-
body { overflow: hidden }导致滚动条消失，body宽度突增约 15px，内容左移——看起来像fixed抽搐，其实是布局跳变
真正可靠的解法，从来不是给 fixed 加更多 hack，而是从结构上绕开它：把滚动容器明确限定在某个 div 内，把 fixed 元素直接挂到 body 下；或者改用 position: sticky（需确保父容器有 overflow: auto 且 iOS ≥ 15.4）；再或者，接受它在键盘场景下的不可靠性，用 absolute + 动态 top 补位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
