核心判断

Safari 滚动卡顿的根源，不在于硬件性能，而在于 WebKit 引擎对 scroll 事件严格的同步约束。

简单来说，只要页面注册了一个没声明 passive 的监听器，Safari 就会把滚动处理降级到主线程上排队等着。直到 Ja vaScript 执行完毕，才肯动一下。

这一等，16ms 的帧率窗口就破了，掉帧卡顿随之而来。

相比之下，Chrome 从 v56 开始就已经对未声明 passive 的监听器做了自动降级处理，默认当成 passive 行为来跑。只在真正调用 preventDefault() 时才报错。

而 Safari 至今还严格遵循 W3C 规范，不做任何自动降级。

根本原因：WebKit渲染管线对scroll事件的强同步约束

macOS 和 iOS 上的 Safari 使用 WebKit 引擎，其滚动输入处理路径和 Chromium 系浏览器有本质差异。

滚动位移本身是由独立的异步合成线程捕获的。但一旦页面上注册了未声明 passive 的 scroll 监听器，WebKit 会立刻将整个滚动容器降级回主线程处理。

所有后续滚动帧都得排队等 JS 回调执行完才能继续。这直接打破了 16ms 的帧率窗口，肉眼可见的滞后和掉帧就此产生。

Chrome 自 v56 起对未显式声明 passive 的 scroll 监听器自动降级为 passive 行为。仅在检测到 preventDefault 调用时才报错。

而 Safari 至今仍严格遵循 W3C 规范，不做自动降级。

触发强制同步布局（Forced Synchronous Layout）

在 scroll 回调里读取 getBoundingClientRect()、offsetTop 或 clientHeight 等属性，会迫使 WebKit 立即计算当前布局树。

这种同步回流在滚动高频触发下会形成雪崩效应。每帧都卡在布局计算上，GPU 合成器无法及时获取最新的图层状态。

关键区别在这里： Safari 的布局计算完全运行在主线程，而且没有 Chromium 那样的布局优先级调度机制。

一旦触发，后续的滚动输入事件就会被暂存，直到本次回流完成。这就是所谓手指一动、页面半拍才响应的底层原因。

图层树损坏导致GPU合成失效

当页面存在大量 position: sticky、嵌套 flex 容器或 transform 动画元素时，Safari 的滚动容器图层树很容易因状态不一致而损坏。

这时候，本该由 GPU 直接合成的滚动帧，被迫回落到 CPU 逐帧重绘。帧率直接从理论上的 120fps 暴跌到 20–30fps。

这种损坏不可见、不报错，只是表现为惯性中断、微卡顿或者偶发白屏。

Chrome 的图层管理明显更鲁棒，同类结构下通常仍能维持 GPU 合成路径。

优化操作路径

要解决这个问题，可以按以下步骤操作：

• 第一步：为所有 scroll 监听器添加 { passive: true } 选项
• 第二步：将 getBoundingClientRect() 调用移出 scroll 回调，改用 resize 事件缓存加 requestAnimationFrame 更新
• 第三步：在 CSS 中为滚动容器添加 -webkit-overflow-scrolling: touch，并确保它有一个明确的 height 或 max-height
• 第四步：禁用系统辅助功能中的「使用键盘控制鼠标」和「切换控制」
• 第五步：关闭 Safari 高级设置中的「Prefer Page Rendering Updates near 60fps」选项，然后按 Command + Q 彻底退出 Safari，再重启

《夸克》非常好用的免费AI浏览器

下载APP查看