先说说一个常见的困惑：用Safari跑大量JavaScript循环时，整个设备仿佛被冻住。

页面点不动，触控没反应，甚至需要强制重启App。这到底是不是Safari的Bug？

主线程被占用的连锁反应

其实并不是真的“整机锁死”。而是主线程被完全占用后引发的连锁反应。

页面失去响应，系统交互延迟加剧。在低配设备上甚至会触发系统级保护机制，表现就是界面冻结、触控无反馈，甚至WebView进程被强制终止。

这并非Safari独有的问题，但它在iOS/macOS上的资源调度策略确实让现象更明显。

JavaScript是单线程运行的。一段未经拆分的for循环如果遍历10万条数据，再加上复杂计算或频繁DOM操作，主线程会被连续占用几百毫秒甚至几秒。这段时间里：

• 页面无法响应点击、滚动、输入
• setTimeout和setInterval回调全部积压，唤醒后也不会补发
• new Date()虽然还能调用，但时间感知已经失真
• Safari不会弹出任何警告——用户只能强退App

低配设备更敏感，Safari没有自动中断

更关键的是低配设备的内存与调度更敏感。像iPhone SE（第二代）、iPad Air 2这些机型，RAM只有2–3GB。

如果循环中还伴随对象创建、JSON序列化、样式重排等操作，内存会瞬间飙升，触发系统的OOM Killer机制。这时候不光是页面崩溃，整个Safari App可能卡住数秒，甚至影响后台其他App的调度响应。

另一个值得注意的点是：Safari没有自动降级或中断机制。

Chrome有较明确的脚本超时提示（大约10秒），Firefox会报错并允许停止。但Safari对长任务的处理更“沉默”——它不主动中断，也不提供window.onbeforeunload这类钩子来捕获异常状态。开发者如果没加防护，用户就只能等待或强制重启。

如何避免这种锁死式卡顿

说一千道一万，写JavaScript时默认得把“不能阻塞主线程”当作铁律，而不是依赖浏览器来兜底。几个实用的方向：

• 把大循环切片：用setTimeout(fn, 0)或queueMicrotask分批执行，每批控制在1000次以内，留出空闲让事件循环继续运转
• 避免在循环里读写DOM：缓存offsetHeight、getBoundingClientRect()这些值，不要每次迭代都触发重排
• CPU密集型任务移交给Web Worker：比如排序、加密、图像处理，主线程只负责通信和UI更新
• 加超时兜底：对关键循环加一个计时器，超过500毫秒未完成就中断，并提示“处理中，请稍候”
• 检测设备能力：用navigator.hardwareConcurrency或简单的内存试探（如performance.memory）来判断是否启用简化逻辑

归根结底，这不是Safari“故意锁死”，而是它严格遵循Web标准，在资源受限的环境下优先保障系统稳定性。理解了这个前提，方案自然就有了方向。

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

下载APP查看