scroll-view 内的 position: fixed 相对于 scroll-view 自身而非视口，iOS 上因 -webkit-overflow-scrolling: touch 加剧错位，稳定方案是将 fixed 元素移出 scroll-view 并用 flex 布局提级。
scroll-view 内部的 position: fixed 不是相对于视口定位
微信小程序中，scroll-view 是一个独立滚动容器，内部的 position: fixed 元素**不会锚定在屏幕视口上**，而是被重新解释为相对 scroll-view 自身定位。这和浏览器标准行为完全不同，是小程序底层 WebView 渲染机制导致的硬限制。
典型现象包括：
-
bottom: 0的按钮卡在scroll-view底部，而不是页面底部 - iOS 上按钮宽度被截断、只显示在可滚动区域宽度内
- 安卓上位置偏移，尤其在低端机型或旧版微信中更明显
这不是 CSS 写错了，也不是兼容性补丁能解决的问题——它源于 scroll-view 组件自身对 fixed 的重定义，官方文档明确将其列为「不推荐用法」。
为什么 -webkit-overflow-scrolling: touch 会让 iOS 更糟
小程序在 iOS 上默认启用 -webkit-overflow-scrolling: touch（提供滚动惯性），但它会创建一个新的堆栈上下文，并干扰 fixed 元素的层叠与定位计算。结果就是：同一个 z-index 和 bottom 值，在开发工具或安卓上正常，在真机 iOS 上却“缩在左下角”或“只显示一半”。
立即学习“前端免费学习笔记（深入）”；
如果你看到弹窗、悬浮按钮只在 scroll-view 区域内渲染，且无法撑满全屏宽度，基本可以判定是这个属性在作祟。禁用它（设为 auto）虽能缓解，但代价是失去滚动回弹效果，且仅对 view + overflow 方案有效——对原生 scroll-view 组件无效。
公众号运营：文章发布至草稿、样式封面、评论与用户管理、数据统计等。用户要求将 Markdown 发送到公众号草稿、查看阅读量统计或类似后台操作时，使用本技能。
替代方案必须把 fixed 元素移出 scroll-view 标签
真正稳定的做法，是放弃在 scroll-view 内部使用 fixed，改用 Flex 布局将固定区域“提级”到同级容器中：
- 外层
view设display: flex; flex-direction: column; height: 100vh; -
scroll-view设flex: 1; overflow: hidden; - 底部按钮等固定内容放在
scroll-view外部，单独一个view，设flex-shrink: 0;
这样既保持滚动区域可控，又让按钮真正“钉”在视口底部。注意：不能只靠 position: fixed 加 z-index 强行覆盖——在 scroll-view 内部加再多层级也绕不开定位基准变更的问题。
有下拉刷新（refresher-enabled）时更要小心
开启 refresher-enabled 后，scroll-view 对 fixed 的处理会进一步失常。部分版本中，刷新控件激活时会强制重置内部定位上下文，导致原本“勉强可用”的 fixed 元素瞬间错位甚至消失。
此时若必须保留下拉刷新，又无法将弹窗/菜单等组件提到外部，唯一可行的折中方式是：在弹窗显示前，动态设置 scroll-y 为 false，并调用 scrollTo 确保 scrollTop 归零——否则弹窗仍会按旧滚动位置计算 fixed 偏移。
这个细节容易被忽略：很多开发者只关了滚动，却没重置滚动位置，结果弹窗一出来就“飘”在半空。
