浏览器没有系统级低功耗模式，其“低功耗”实为操作系统或浏览器通过节流javascript定时器（如拉长setinterval间隔、暂停requestanimationframe、放大settimeout延迟）实现的资源优化策略，需用page visibility api、requestidlecallback和web push等机制适配。
浏览器本身没有“低功耗模式”这一系统级运行状态——它不直接参与芯片级的 Sleep/Stop/Standby 等电源管理，也不会像 STM32 或 AC632N 那样关闭主时钟、门控外设。所谓“浏览器低功耗模式”，实际是操作系统（如 Windows、macOS、Android、iOS）或浏览器自身为节省电量而采取的一系列资源节流策略，其核心影响对象是 JavaScript 的定时器行为（setTimeout、setInterval、requestIdleCallback 等），而非硬件定时器。
浏览器定时器在系统节电状态下的典型表现
后台标签页被大幅限频
当标签页切换到后台，且系统进入节能状态（如笔记本合盖、手机屏幕熄灭），Chrome/Firefox/Safari 会主动将setInterval最小间隔从 1ms 拉长至 1000ms（即 1 秒），即使代码设为setInterval(fn, 10)，实际触发也几乎固定在秒级。这是防止单页应用持续占用 CPU 导致发热与耗电。页面不可见时暂停 requestAnimationFrame
requestAnimationFrame在页面不可见（document.hidden === true）时完全停止回调，不会累积帧请求。恢复可见后，首次回调可能跳过若干帧，但不会补帧。setTimeout/setInterval 的延迟被放大且不保证精度
实测显示：在 macOS 合盖休眠前几秒、Windows 电池模式下，或 Android 后台进程被系统压缩时，原定 500ms 的setTimeout可能延迟 2–8 秒才执行；若设备进入深度睡眠（S3/S4），JavaScript 引擎已暂停，定时器根本不会触发，直到系统唤醒并恢复浏览器进程。Web Workers 行为更保守，但未必更可靠
即使使用 Dedicated Worker 或 Service Worker，只要宿主页面被冻结或进程被挂起，Worker 也会同步受限。Service Worker 的fetch和push事件仍可唤醒，但纯定时任务（如self.setTimeout）在无活跃上下文时同样被节流或丢弃。
如何应对？关键不是“抗节流”，而是适配机制
✅ 用
Page Visibility API主动感知状态
监听visibilitychange事件，在document.hidden为true时暂停轮询逻辑，保存当前进度；恢复时重新计算偏移量，避免“醒来就狂发请求”。✅ 优先使用
requestIdleCallback处理非紧急任务
它天然适配系统负载，空闲时才执行，比setTimeout(..., 0)更省电、更友好。✅ 对强时效任务，改用服务端触发（如 Web Push）
浏览器无法保证本地定时器准时，但服务器可在精确时刻推送消息，由 Service Worker 接收并唤醒页面（需用户授权）。❌ 不要依赖
performance.now()或Date.now()做长时间跨度的精度校准
系统休眠期间时间戳不会推进，醒来后Date.now()是连续的，但performance.now()可能因引擎暂停而丢失毫秒级连续性，导致差值失真。
本质上，这不是定时器“坏了”，而是浏览器在配合系统做合理让渡：把有限的 CPU、内存和电量留给前台任务和系统服务。设计前端定时逻辑时，得默认它“不可靠”，再用状态同步、服务协同和用户反馈来兜底。
