移动端 fixed 定位在 iOS Safari 和部分 Android WebView 中常失效，主因是祖先元素的 transform、perspective 等触发新 containing block，使其退化为 relative 定位；优先用 sticky 替代，必要时用 JS 模拟并监听 scroll/resize/keyboard 事件。
fixed 定位在 iOS Safari 和部分 Android WebView 中不“真固定”
移动端的 position: fixed 并非真正意义上的视口固定——它常随页面滚动产生延迟、跳动，甚至在键盘弹出、横竖屏切换、页面缩放后完全失效。根本原因在于：iOS Safari（尤其 12–15）和许多基于旧版 Chromium 的 Android WebView 对 fixed 的实现依赖于合成层触发，而滚动容器、overflow: scroll、-webkit-overflow-scrolling: touch 等都会打断该层，导致元素“跟着滚”。
检查是否被父容器的 transform 或 perspective 干扰
这是最隐蔽也最高频的失效原因。只要任意祖先元素设置了 transform（哪怕只是 transform: translateZ(0)）、perspective、filter 或 will-change，就会创建新的 stacking context 和 containing block，使 fixed 元素改为相对于该祖先定位（即退化为 absolute）。
- 用浏览器开发者工具逐级检查
Computed面板，看是否有意外的transform值 - 临时移除疑似父容器的
transform或will-change声明，观察是否恢复 - 避免为滚动区域外的 wrapper 添加
transform: translateZ(0)来“强制硬件加速”——这反而会破坏fixed
替代方案：用 position: sticky + 占位容器兜底
当目标元素位于页面顶部或底部且不需要跨滚动容器悬浮时，position: sticky 是更可靠的选择。它天然兼容 iOS Safari 11+ 和 Chrome 56+，且不受 transform 祖先影响。
.header {
position: -webkit-sticky;
position: sticky;
top: 0;
z-index: 100;
}
/ 必须确保其父容器有明确高度或内容流，否则 sticky 不触发 /
.main-content {
min-height: 100vh;
}
注意：sticky 要求元素在文档流中有自然位置，且其最近的滚动祖先（通常是 或带 overflow-y: scroll 的容器）必须可滚动；若需底部吸附，用 bottom: 0，但需保证父容器高度足够。
立即学习“前端免费学习笔记（深入）”；
必须用 fixed？那就手动模拟 + 监听 scroll/resize
仅当需要穿透滚动容器、悬浮在键盘上方、或做全局 toast/bar 时，才考虑 JavaScript 模拟。关键点不是“重写 fixed”，而是规避原生限制：
- 将元素移出所有滚动容器，直接挂载到
document.body下 - 监听
scroll和resize（含orientationchange），用getBoundingClientRect()动态计算视口坐标 - 避免高频
scroll触发重排：使用requestAnimationFrame节流 - 键盘弹出时，iOS 会改变
window.innerHeight，需监听focusin/focusout事件修正偏移
这类方案维护成本高，且在快速滚动或低性能设备上仍有卡顿，只建议作为最后手段。
真正棘手的从来不是“怎么写 fixed”，而是“谁把它悄悄改成了 relative”。查祖先的 transform、确认滚动上下文、优先用 sticky——这些动作比加一行 !important 有用得多。
