fixed弹窗滑动导致底层页面滚动是滚动穿透而非定位失效，主因是touchmove事件冒泡至body；解决方案包括body加position: fixed并同步存取scrollTop、避免在scroll-view内使用fixed、软键盘场景改用absolute动态对齐。
fixed定位在H5移动端“穿透”不是CSS错，而是滚动事件冒泡到body导致下层页面滚动——本质是滚动穿透（scroll through），不是定位失效。
为什么fixed弹窗一滑动，底下的页面也跟着滚
这不是bug，是移动端浏览器默认行为：当弹窗内容可滚动（比如scroll-view或内部有长列表），但容器没阻止touchmove冒泡时，事件会一路传到body，触发页面整体滚动。iOS尤其明显，因为-webkit-overflow-scrolling: touch开启后，滚动更“贪心”。
常见诱因包括：
- 弹窗未加
touchmove.prevent，或加了但只作用于遮罩层，漏掉内部滚动区 - 使用
scroll-view组件时，其内部滚动不拦截外部事件，且uni-app的scroll-view自带transform，可能同时引发fixed退化+滚动穿透双重问题 - 用
body { overflow: hidden }但没处理滚动位置保存，关闭后无法恢复，用户感知为“页面跳了”
用body { position: fixed }锁住页面最稳
比overflow: hidden更可靠，能100%阻断滚动穿透，且兼容所有iOS/Android WebView（包括旧版QQ、UC）。
立即学习“前端免费学习笔记（深入）”；
关键点在于必须同步记录并还原scrollTop：
- 打开弹窗前，用
document.scrollingElement.scrollTop存当前值（兼容document.body和document.documentElement） - 设置
document.body.style.top = -scrollTop + 'px'，再加position: fixed，视觉上页面就“钉住”了 - 关闭弹窗时，先移除
position: fixed，再document.scrollingElement.scrollTop = scrollTop - 注意iOS Safari中
scrollTop恢复可能有1帧延迟，加setTimeout(() => {}, 0)或requestAnimationFrame兜底
避免在scroll-view里放fixed元素
uni-app的scroll-view内部强制创建滚动上下文，只要fixed元素写在它里面，无论加多少!important或transform: translateZ(0)都无效——iOS Safari直接无视，安卓部分WebView也会降级为relative。
正确做法是：
- 把需要fixed的按钮、导航条等，用
<teleport to="body">（Vue 3）或document.body.appendChild（H5端）强行挂到body最外层 - 确保这些元素不在任何
scroll-view、uni-page、或带transform的容器内 - 若必须动态控制显隐，用
v-if而非v-show，避免DOM残留干扰定位上下文
软键盘弹起时fixed元素上浮，其实是视口被压缩
Android多数浏览器（Chrome、微信）软键盘弹出时会缩小window.innerHeight，导致100vh变小，bottom: 20px就往上跑；iOS则常保持视口高度但滚动锚点偏移。
别依赖resize事件粗略判断——它在键盘收起后才触发，用户已看到错位。更准的做法是：
- 监听
uni.onKeyboardHeightChanged（H5端需自行封装input:focus+setTimeout测高） - 键盘弹起时，把fixed元素临时切为
position: absolute，top: calc(100% - 152rpx)（152rpx≈按钮高度+安全距离） - 键盘收起后，立刻切回
position: fixed，不要等blur，否则有延迟
真正难搞的是横屏+软键盘+fixed三者叠加：坐标系旋转、视口压缩、定位上下文重置全撞一起。这种场景建议直接放弃fixed，改用absolute + requestAnimationFrame实时对齐视口底部——虽然多几行JS，但稳定得多。
