Safari执行大规模JS循环会导致主线程被垄断，使页面无响应、系统交互延迟加剧，甚至触发OOM Killer机制强制终止进程；应通过任务切片、Web Worker移交、DOM操作优化及超时兜底等手段避免。
Safari浏览器执行大规模循环JS代码时导致整机锁死，本质不是“整机”真被锁死，而是主线程被完全占用，使页面失去响应、系统交互延迟加剧，尤其在低配设备上会触发系统级保护机制，表现为界面冻结、触控无反馈、甚至WebView进程被强制终止。
这不是Safari独有的问题，但其在iOS/macOS上的资源调度策略会让现象更明显：单线程JavaScript持续运行，阻塞渲染、事件处理、定时器回调，连requestAnimationFrame和visibilitychange都失效；同时系统检测到页面长时间无响应，可能主动回收内存或杀掉Web进程，造成闪退或白屏。
以下几点是关键原因和应对方向：
主线程被长任务彻底垄断
JavaScript在浏览器中运行于单线程主线程。一个未拆分的for循环遍历10万条数据、做复杂计算或DOM操作，会连续占用主线程数百毫秒甚至数秒。期间：
- 页面无法响应点击、滚动、输入
-
setTimeout/setInterval回调积压不执行（唤醒后也不会补发） -
new Date()仍可调用，但时间感知失真 - Safari不会弹出警告，用户只能强退App
低配设备内存与调度更敏感
iPhone SE（第二代）、iPad Air 2等机型RAM仅2–3GB，若循环中还伴随对象创建、JSON序列化、样式重排等操作，内存瞬时飙升，触发系统OOM Killer机制。此时不只是页面崩溃，整个Safari App可能卡住数秒，甚至影响后台其他App的调度响应。
没有自动降级或中断机制
Chrome有较明确的脚本超时提示（约10秒），Firefox会报错并允许停止；而Safari对长任务更“沉默”——它不主动中断，也不提供window.onbeforeunload类钩子来捕获异常状态。开发者若没加防护，用户就只能等待或强制重启。
如何避免这种锁死式卡顿
- 把大循环切片：用
setTimeout(fn, 0)或queueMicrotask分批执行，每批≤1000次，留出空闲让事件循环继续 - 避免在循环里读写DOM：缓存
offsetHeight、getBoundingClientRect()等值，不要每次迭代都触发重排 - CPU密集型任务移交Web Worker：如排序、加密、图像处理，主线程只负责通信与UI更新
- 加超时兜底：对关键循环加计时器，超过500ms未完成就中断并提示“处理中，请稍候”
- 检测设备能力：用
navigator.hardwareConcurrency或简单内存试探（如performance.memory）判断是否启用简化逻辑
本质上，这不是Safari“故意锁死”，而是它严格遵循Web标准，在资源受限环境下优先保障系统稳定性。写JS时，默认应把“不能阻塞主线程”当作铁律，而不是依赖浏览器兜底。
