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

iOS Safari锁屏时会冻结JavaScript执行，导致倒计时停止；应使用服务端结束时间戳配合实时new Date()计算剩余时间，并用requestAnimationFrame驱动UI更新。

当你在iPhone上用Safari打开一个带倒计时的H5页面，锁屏5分钟后再点亮屏幕，发现倒计时卡在原地没动、或者只跳了十几秒——这不是代码写错了，而是Safari在系统休眠期间主动终止了JavaScript执行环境。iOS从13开始强制冻结所有后台页面的JS线程，包括setInterval、setTimeout甚至requestAnimationFrame，且不提供恢复回调机制。

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

苹果将休眠状态下的网页脚本执行视为高风险行为。一旦设备锁屏，Safari进程被系统挂起，所有JS上下文（含定时器句柄、闭包变量、EventLoop队列）全部冻结。此时new Date()仍可调用，但定时器回调永远不会触发——不是延迟，是彻底停摆。唤醒后，浏览器不会自动重放积压的定时器任务，也不会通知你“我刚刚睡了多久”。

这与Android碎片化节流不同：iOS策略是硬性、不可绕过、无例外的。即使你用Web Workers或Service Worker，只要主页面不可见，它们同样被暂停。官方文档明确指出：“【Safari does not execute JavaScript while the device is asleep】”。

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()结果。每次都要实时调用，否则在长时间休眠后，若用上次记录的时间做减法，误差会累积放大。这一步必须每帧都取当前系统时间。