Web Worker 无定时器补偿机制，需用 Page Visibility API 协同实现逻辑时间校准：主线程通知挂起/恢复，Worker 累计 pausedDuration 并基于 baseTime 与真实时间轮询调度，辅以服务端时间同步修正漂移。
HTML5 中的 Web Worker 本身不提供“定时器补偿机制”，浏览器在标签页进入后台时会主动降频甚至暂停 setTimeout 和 setInterval，这是为了节省资源，Worker 内部的定时器同样受此限制。但你可以通过页面可见性（Page Visibility API）配合 Worker 协同策略，实现逻辑上的“时间补偿”——即感知挂起时段、记录偏移、恢复后校准任务节奏。关键不在绕过限制，而在合理建模时间状态。
用 Page Visibility API 感知前台/后台切换
Worker 无法直接访问 document.hidden，所以需由主线程监听并通知 Worker：
- 主线程监听
visibilitychange事件，当document.hidden === true时，立即向 Worker 发送{ type: 'pause', timestamp: Date.now() } - 当切回前台时，发送
{ type: 'resume', timestamp: Date.now() } - Worker 内维护一个累计挂起时长（pausedDuration），每次 resume 时叠加差值
Worker 内部用逻辑时钟替代物理定时器
不要依赖 setInterval(fn, 1000) 做精确秒级调度。改用基于时间戳的轮询+校准：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 启动时记录初始基准时间
baseTime = Date.now() - 用
requestIdleCallback或短周期setTimeout(..., 50)轮询当前真实时间 - 计算“应触发时刻” =
baseTime + 已计划间隔 × 触发次数 + pausedDuration - 若当前真实时间 ≥ 应触发时刻，则执行任务，并递增计数；否则继续等待
对高精度场景补充时间同步机制
长时间挂起可能导致累积误差变大。可定期与服务端时间或主线程同步：
- 主线程每隔 30 秒向 Worker 发送一次
{ type: 'sync', serverTime: xxx, localTime: Date.now() } - Worker 根据往返延迟估算时钟漂移，动态调整
baseTime或补偿因子 - 适用于倒计时、心跳上报、离线任务调度等需跨会话保持时间一致性的场景
避免常见误区
有些做法看似“补偿”，实则无效或有害：
- 在 Worker 中使用
new Date().getTime()对比上次触发时间 —— 这能检测跳变，但无法自动恢复节奏，仍需你手动重排计划 - 尝试用
performance.now()替代Date.now()—— 它不受系统时间修改影响，但同样被后台节流，且不解决挂起导致的逻辑断点 - 在主线程中用
pagehide/pageshow代替visibilitychange—— 前者只在页面卸载/重载时触发，无法捕获标签页最小化或切换等常见后台行为
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
