iOS Safari弹性滚动时会错误移除sticky元素导致空白，根本原因是其滚动锚定逻辑缺陷；有效方案是body加overscroll-behavior:none或用IntersectionObserver+scrollend动态切换fixed/sticky。
不是 CSS 写错了，是 Safari 在弹性滚动（overscroll）时主动丢弃了 sticky 元素的渲染——加 will-change 或硬件加速完全无效，反而加重内存压力。
为什么 iOS Safari 滚动到顶/底时 sticky 元素突然变空白
iOS 的弹性滚动会让视口短暂“滑出”文档边界（比如手指快速上划过头），此时 Safari 会错误判定 sticky 元素已“滚出可视区域”，直接从渲染树中移除它。这不是重绘延迟，是彻底不画——所以 DevTools 里元素还存在，但 Computed 中 position 可能仍显示 sticky，而视觉上就是一帧空白。
这个行为在 iOS ≤16.4 中尤为顽固，且与父容器样式、transform、will-change 都无关，纯属浏览器滚动锚定逻辑缺陷。
- 验证方式：在 Safari 开发者工具中手动拖拽滚动条到顶部后继续拖——只要出现 overscroll，sticky 元素就大概率消失
- 安卓或 macOS Safari 不会出现，因为它们没有弹性滚动机制
- 加
backface-visibility: hidden或translateZ(0)不能修复，只会让合成层更混乱
真正有效的两个应对方案
别试图“修 sticky”，要绕过它的失效窗口：
立即学习“前端免费学习笔记（深入）”；
- 在
<body>上加overscroll-behavior: none，禁用弹性滚动——这是最轻量、最稳定的解法，但会牺牲 iOS 特有的“回弹感” - 降级为
position: relative+IntersectionObserver+scrollend事件监听：只在用户真正停止滚动后才切换成position: fixed，并在scrollend触发后再 1 帧切回sticky；不用setTimeout猜时间点 - 必须配合
@supports not (position: sticky)做兜底，不能只靠 JS 检测CSS.supports()，旧版 Safari 可能返回true却不执行
为什么给 sticky 元素加 transform 或 filter 后更糟
只要 sticky 元素或其任意祖先有 transform、filter、will-change，Safari 就会创建新的 containing block 和滚动上下文，导致 sticky 定位基准从视口变成那个 transform 容器——结果不是闪烁，是吸顶位置错乱甚至完全不触发。
- 常见藏雷点：
.van-card、.ant-modal-body、Swiper wrapper 默认带overflow: hidden，而它和transform组合会双重破坏 sticky - 检查方法：在 Safari DevTools 中逐级点击父节点，看 Computed 里的
overflow-x和transform是否非none - 替代方案：用
clip-path: inset(0)替代overflow: hidden，它不创建新 BFC，也不干扰定位上下文
容易被忽略的关键细节
很多人以为“只要没报错、DevTools 显示 position: sticky 就没问题”，但 iOS 上 sticky 的失效是静默的——Computed 值不变，渲染却停了。更麻烦的是，这种失效只在特定滚动速度、特定 overscroll 幅度下触发，本地测试很难复现，必须真机连 Safari 调试器，用触控板模拟快速滑动+过冲才能稳定捕捉。
