为什么Safari浏览器在系统休眠唤醒后前端的部分JS定时器任务会失效？

先说几个关键判断。iOS Safari锁屏时Ja vaScript执行会被彻底中断，这事儿不是bug，是系统设计上的硬性策略。如果你正在开发一个依赖前端倒计时的H5页面，最好提前想清楚：用户锁屏几分钟再回来，界面上的时间很可能就“卡住”了。

具体表现是这样：你用iPhone打开一个活动倒计时页面，锁屏五分钟，再点亮屏幕，倒计时要么纹丝不动，要么只跳了十几秒。代码逻辑看着没问题，但问题不在代码本身——是Safari在系统休眠期间主动冻结了Ja vaScript执行环境。

根本原因：系统级资源管控

苹果把锁屏状态下网页脚本的执行视为高风险行为。一旦设备锁屏，Safari进程被系统挂起，所有的JS上下文——包括定时器句柄、闭包变量、EventLoop队列——全部被冻结。这时候new Date()其实还能调用，但定时器的回调永远不会触发。不是延迟，是彻底停摆。唤醒之后，浏览器既不会自动重放积压的定时器任务，也不会告诉你“我已经睡了多久”。

这和Android碎片化的节流策略完全不同。iOS的策略是硬性、不可绕过、毫无例外的。哪怕你用Web Workers或者Service Worker，只要主页面不可见，它们同样会被暂停。官方文档写得很清楚：“

”。这句话值得所有前端开发者记住。

visibilitychange事件无法捕获休眠过程

你可能想过用document.addEventListener('visibilitychange', ...)来监听休眠状态。但实测下来问题很大：iPhone锁屏的瞬间，visibilityState仍然显示为'visible'，大约要过30秒才可能变成'hidden'，而且设备唤醒时这个事件根本不触发。靠它来做“休眠起止标记”基本行不通。

更要命的是，这个事件在iOS Safari上存在兼容性断层。部分旧版本根本不支持这个API，而新版本又因为休眠机制导致事件时机完全错乱。所以，别把它当作可靠的状态同步信标。

修复方案：用服务端时间戳驱动倒计时

那怎么办呢？解决方案其实很直接——放弃依赖本地定时器的连续性，改由服务端时间戳来主导计算。

第一步：向后端请求活动的结束时间戳，比如1717406880000，把它存入本地变量endTime。

第二步：每次渲染之前计算差值——Math.max(0, endTime - new Date().getTime())，然后直接转换成剩余时分秒。

第三步：用requestAnimationFrame替代setInterval来驱动UI更新。它天然会跳过隐藏帧，避免无效计算，而且在前台时能保持60fps的平滑刷新。

必须警惕的是：千万不要缓存new Date()的结果。每次都要实时调用。如果长时间休眠后还用上次记录的时间做减法，误差会像滚雪球一样越滚越大。这一步必须每帧都取当前系统时间。

说到底，在iOS Safari上做倒计时，核心就一句话：把时间计算的锚点放在服务端，让前端只做一个“从当前时间算差值”的显示器。这样不管用户锁屏多久，点亮屏幕的那一刻，看到的一定是正确的时间。