fixed在移动端“失效”是因iOS Safari和安卓WebView将fixed锚定于最近可滚动祖先或新包含块而非视口；受transform/filter/opacity影响，且需注意键盘弹出、伪元素配置及横屏坐标映射等细节。
为什么fixed在移动端会“失效”而不是写错了
不是你CSS写错，而是iOS Safari和多数安卓WebView把position: fixed锚定在“最近可滚动祖先”或“新包含块”上，而非视口。一旦父级有transform、filter、opacity（backdrop-filter或will-change，fixed就退化为relative定位——看起来就是“跟着滚”“卡在半空”“点不中”。软键盘弹出、横屏旋转、页面缩放时，这种退化会被放大。
怎么快速定位是哪个父级在破坏fixed
别靠猜，用开发者工具逐层检查：
- 选中失效的fixed元素，在Elements面板按住
Shift连续点击右上角箭头，逐级跳到父节点 - 每跳一层，切到Computed标签页，搜索
transform、filter、will-change - 重点盯
transform: translateZ(0)——它没动画面，但已创建新定位上下文 - 顺手看
opacity是否小于1，某些UI库默认设opacity: .99也会触发
真正能落地的三种修复路径
单纯加!important或临时删transform只是掩盖问题，稳定解法要分场景：
- 结构可控时：用
<teleport to="body"></teleport>（Vue）或createPortal（React）把fixed元素挂到<body>下，彻底绕过所有父级干扰 - 小程序或uni-app H5：fixed元素绝不能写在
<scroll-view>内部；外层用display: flex; flex-direction: column; height: 100vh，<scroll-view>设flex: 1，按钮放同级并加position: fixed; bottom: 0; left: 0; right: 0 - 键盘/缩放高频场景：放弃fixed，改用
position: absolute+ 动态计算；监听focusin/blur，用setTimeout(() => { ... }, 0)延迟读取getBoundingClientRect()，再算window.innerHeight - inputRect.bottom设bottom值
容易被忽略的硬性约束
哪怕方案选对，漏掉这些细节照样穿帮：
立即学习“前端免费学习笔记（深入）”；
-
position: absolute替代fixed时，根容器必须设position: relative和min-height: 100vh（不能只写height: 100%，否则键盘弹出时塌陷） - 伪元素实现
background-attachment: fixed时，::before必须有content: ""、四边全为0、z-index: -1、pointer-events: none，缺一不可 - 横屏下H5的fixed彻底错乱，是因为整个页面被
transform: rotate(90deg)模拟，坐标系已旋转——此时top: 0实际可能贴左下角，必须手动映射坐标或禁用横屏fixed
