打开一个数据看板、在线IDE或者实时协作文档，Safari的响应速度突然变得像是上了年纪的老人——滚动掉帧、点击按钮半天没反馈，甚至整个页面卡死好几秒。别急着怪网速，真相是：JavaScript执行已经死死堵住了主线程。

主线程被长任务彻底垄断

JavaScript在Safari中是单一线程运行的。

一个没有拆分的for循环，遍历10万条数据，同时反复读写DOM，或者同步解析一个巨型JSON。这些操作会连续占用主线程几百毫秒甚至更久。

此时页面根本顾不上响应点击、滚动、输入。setTimeout回调积压成一堆，requestAnimationFrame也失效了，连visibilitychange事件都收不到。

【关键前提】Safari不会主动中断这类长任务，也不弹出“脚本无响应”提示——用户只能等待或者强制重启，没有第二条路。

低配设备触发OOM Killer机制

像iPhone SE（第二代）、iPad Air 2这些只有2-3GB内存的老机型，如果JS循环里还掺杂着Canvas重绘、频繁创建对象、样式重排，内存量会瞬间飙升。

系统检测到WebProcess进程异常，就会拉响警报，直接启动OOM Killer，强制终止进程。

结果不只是网页崩溃，而是整个Safari App卡住好几秒，后台其他App的调度也会受到影响。

后台标签页持续抢占资源

你或许开了12个标签页，其中9个早就切走了。但它们还在后台悄悄运行轮询脚本、维持WebSocket心跳、监听键盘事件。

这些任务持续占用CPU时间片，直接拖垮前台页面的60fps渲染帧率。相当于一群不请自来的客人，占着沙发不走，你坐在旁边自然动弹不得。

解决路径：从执行切片到任务剥离

方法一：用queueMicrotask切片执行

把大循环拆成每批不超过1000次，每次执行完让出控制权，浏览器就能插空处理点击、滚动这些急事。代码像这样：

function processBatch(start, end) { /* 处理start到end的数据 */ }
function runInBatches(data, batchSize = 1000) {
  let i = 0;
  function next() {
    if (i < data.length) {
      const end = Math.min(i + batchSize, data.length);
      processBatch(i, end);
      i = end;
      queueMicrotask(next);
    }
  }
  next();
}

方法二：移交CPU密集型任务至Web Worker

排序、加密、图像处理这些重活儿，别在主线程上做。交给Worker去跑，跑完再postMessage传回结果，主线程只管更新UI，一分工都不多占。

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

下载APP查看