uni-app 的 position: fixed 在 H5 移动端失效主因是祖先元素设置 transform/filter/opacity 等触发新包含块，使 fixed 退化为相对该祖先定位；应将元素移至 body 下、优先用 sticky 替代，或使用 var(--window-top) 等 uni-app 专用适配方案。
uni-app 的 position: fixed 在 H5 端移动端（尤其是 iOS Safari 和部分 Android WebView）频繁失效，不是写法错，而是浏览器底层对 fixed 的实现被干扰——它常退化为 relative 或 absolute 行为，根本原因几乎都指向「祖先元素创建了新包含块」。
为什么 fixed 在 H5 移动端突然“跟着滚动”
这不是 bug，是 CSS 规范行为：只要任意父级（哪怕隔了 5 层）设置了以下任一属性，position: fixed 就会失去相对于视口的定位能力，转而相对于该父级定位：
-
transform值不为none（包括translateZ(0)、scale(1)、rotate(0)） -
filter值不为none（哪怕blur(0)或opacity(1)写法错误也会触发） -
opacity小于1 -
backdrop-filter、will-change
uni-app 中尤其常见于：scroll-view 组件内部、第三方弹窗/轮播图组件、全局缩放容器（如 #scale-box）、甚至 uni-page-head 自带的 transform 动画。真机上软键盘弹出、横竖屏切换时，这种失效会叠加放大。
如何快速定位哪个父级在“搞破坏”
别靠猜，用 Chrome 或 Safari 真机远程调试（Remote Debugging）直接查 computed 样式：
立即学习“前端免费学习笔记（深入）”；
- 选中失效的 fixed 元素，在 Elements 面板按住 Shift + ↑ 逐层跳转父节点
- 每跳一层，切到 Computed 标签页，搜索
transform、filter、opacity - 重点盯
transform: translateZ(0)—— 它不改变位置，但已创建新包含块 - 临时加
transform: none !important到疑似父级，看 fixed 是否恢复（仅用于验证）
注意：uni-app 的 uni-page 或 page 根节点有时也被框架注入了 transform，需一并检查。
真正有效的修复方案（不是 hack）
修复必须从 DOM 结构或定位策略入手，而不是强行覆盖样式：
- 把 fixed 元素从带
transform/filter的容器里“拎出来”，直接挂载到<body>下：uni-app 中可用<teleport to="body">（Vue 3）或手动 append 到 body（Vue 2） - 优先改用
position: sticky：对顶部/底部导航、按钮等场景完全够用，且不受 transform 干扰；配合top: 0或bottom: 0即可，iOS Safari 11+ 全面支持 - 避免在非必要容器上加
translateZ(0)“硬件加速”——它在移动端反而破坏 fixed，得不偿失 - 慎用 JS 监听
scroll手动设top：性能差、抖动明显，且软键盘弹出时getBoundingClientRect()返回坐标不可靠
特别提醒：H5 软键盘弹起时，iOS 会临时解除 fixed 锚定，此时 sticky 更稳；若必须用 fixed，建议监听 focus/blur 临时切为 absolute，而非硬扛。
uni-app 特定场景绕过技巧
针对 uni-app 框架自身限制，有些轻量适配可快速落地：
- H5 顶部固定栏：用
top: var(--window-top)替代top: 0，自动兼容导航栏高度（仅 H5 有效） - 底部按钮防键盘顶起：不用
bottom，改用top: calc(100vh - 152rpx)（152rpx 为按钮高+安全距），避开软键盘重绘逻辑 - App 端单独配置：在
manifest.json的"app-plus"节点加"softinputMode": "adjustPan"，减少输入时布局挤压
最易被忽略的一点：所有修复必须在真机上验证——模拟器无法复现软键盘、缩放、合成层打断等真实场景，而这些恰恰是 fixed 失效的高频触发点。
