移动端position: fixed失效主因是祖先元素创建新包含块，导致其退化为relative/absolute定位；根本原因包括transform/filter/opacity等属性触发新包含块，viewport配置不全、软键盘挤压视口亦加剧该问题。
移动端 position: fixed 失效，不是你写错了，而是浏览器（尤其是 iOS Safari 和部分 Android WebView）在特定条件下主动把它“降级”了——它不再相对于视口定位，而是退化为相对于某个祖先元素的 position: absolute。根本原因几乎都指向同一件事：**祖先元素创建了新包含块（containing block）**。
为什么 fixed 会退化成 relative/absolute
只要任意父级（哪怕隔了多层）设置了以下任一 CSS 属性，position: fixed 就会失效：
-
transform值不为none（包括translateZ(0)、scale(1)、rotate(0)） -
filter值不为none（哪怕只是blur(0)或opacity(1)写法有误） -
opacity小于 1 -
backdrop-filter或will-change
这些属性会触发新层叠上下文和新包含块，导致 fixed 元素的“锚点”从视口变成该祖先容器。uni-app 中尤其常见于 scroll-view、弹窗组件、轮播图、甚至 uni-page-head 自带的动画。
如何快速定位是哪个父级在“搞破坏”
别靠猜，用真机远程调试（Chrome DevTools 或 Safari Web Inspector）直接查 computed 样式：
立即学习“前端免费学习笔记（深入）”；
- 选中失效的 fixed 元素，在 Elements 面板按住
Shift + ↑逐层跳转父节点 - 每跳一层，切到 Computed 标签页，搜索
transform、filter、opacity - 重点盯
transform: translateZ(0)—— 它看起来没动，但已创建新包含块 - 临时加
transform: none !important到疑似父级，看 fixed 是否恢复（仅用于验证）
注意：uni-page 或页面根节点有时被框架注入了 transform 动画，也要一并检查。
viewport meta 不全也会让 fixed 锚点错位
只写 <meta name="viewport" content="width=device-width"> 是不够的。iOS Safari 会因字体大小或内容自动调整缩放，破坏 fixed 的坐标系基础：
- 必须同时配齐：
width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no - 漏掉
maximum-scale=1.0，双击放大仍有效；漏掉initial-scale=1.0，小字体页面可能被放大 - 即使 meta 正确，若祖先含
transform或overflow: hidden，fixed 仍会退化
100vw 在 iOS 里也不等于屏幕宽度（含滚动条），建议用 left: 0; right: 0; 替代 width: 100vw。
软键盘弹出时 fixed 为什么“掉下来”
iOS 不把软键盘当作视口变化，而是直接挤压可视区域。window.innerHeight 可能延迟更新甚至不变，而 fixed 元素仍按旧值计算位置：
- 监听
focusin/blur事件，聚焦时改用position: absolute并动态算bottom - 计算要用
window.innerHeight - inputRect.bottom，不是inputRect.top，也不是写死数值 - 用
setTimeout(() => { ... }, 0)确保取到键盘展开后的最新布局 - blur 后必须立刻恢复
position: fixed和bottom: 0，否则滚动时元素会消失
真正麻烦的不是怎么写 CSS，而是不同机型、不同 WebView 对 visualViewport、getBoundingClientRect()、scrollTo 的响应节奏不一致——真机测试比模拟器关键，尤其要测缩放+横竖屏+键盘三连击场景。
