PeriodicBackgroundSync 已被废弃,Chrome 90+ 彻底禁用、Firefox/Safari 从未支持,W3C 标准标记为“Inactive”;可用 BackgroundSync 结合网络恢复、页面可见性或 Push API 模拟近似周期同步。

PeriodicBackgroundSync 不是当前可用的 Web API。浏览器目前不支持该接口,所有尝试调用 navigator.periodicSync.register() 的代码都会抛出 TypeError: navigator.periodicSync is undefined 或类似错误。
这和已落地的 BackgroundSync(即 sync event)不同——后者依赖手动触发注册、靠网络恢复事件驱动,而 PeriodicBackgroundSync 原本设计为「按周期自动唤醒 Service Worker 同步」,但因隐私与功耗争议,Chrome 于 2021 年移除了实验性实现,此后未被任何主流浏览器启用。
PeriodicBackgroundSync 为什么用不了
- Chrome 90+ 已彻底禁用该 API,
navigator.periodicSync永远为undefined - Firefox、Safari 从未实现,也无明确计划支持
- W3C 规范已进入 “Inactive”状态(2023 年标记),实际等同废弃
你看到的旧教程或 MDN 文档片段,大概率来自 2020–2021 年的实验阶段快照,现在直接复制会失败。
替代方案:用 BackgroundSync + 定时逻辑模拟“定期”
虽然不能真正周期唤醒,但可结合以下方式达成近似效果:
- 使用
setInterval()在页面活跃时主动触发同步请求(仅限前台) - 利用
push事件 + 后端定时推送唤醒 Service Worker(需Push API权限和用户授权) - 在关键节点(如页面加载、tab 切入、网络恢复)检查并执行同步逻辑
例如,在 Service Worker 中监听网络恢复后,记录上次同步时间,并在下次恢复时判断是否超过预定间隔:
self.addEventListener('sync', async (event) => {
if (event.tag === 'periodic-data-sync') {
const lastSync = await caches.match('/last-sync-time');
const now = Date.now();
const interval = 24 * 60 * 60 * 1000; // 24 小时
if (!lastSync || now - parseInt(await lastSync.text()) > interval) {
event.waitUntil(syncData());
await caches.put('/last-sync-time', new Response(now.toString()));
}
}
});
注意:sync 事件本身不保证定时发生,只响应网络恢复,所以它只是“机会型同步”,不是“周期型”。
真正需要定期后台任务?考虑这些现实约束
- 浏览器禁止无用户交互的后台定时唤醒(防滥用、保续航)
-
setTimeout/setInterval在页面非活跃或 tab 被冻结时会大幅降频甚至暂停 -
Push API是目前唯一能跨设备/跨会话触发后台执行的机制,但它依赖通知权限,且推送需服务端主动发起
如果你的应用场景必须做到“每天凌晨同步一次日志”,那得由后端发起 push,前端只负责接收并执行;否则,只能接受“用户打开页面时顺带同步”的弱周期模型。
最常被忽略的一点:所谓“定期同步”,往往其实是“用户预期中的定期”,而非技术上严格准时——只要数据最终一致、不丢失、延迟可接受,用网络恢复 + 页面可见性组合触发,反而更可靠、更省电、更兼容。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!











