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，前端只负责接收并执行；否则，只能接受“用户打开页面时顺带同步”的弱周期模型。
最常被忽略的一点：所谓“定期同步”，往往其实是“用户预期中的定期”，而非技术上严格准时——只要数据最终一致、不丢失、延迟可接受，用网络恢复 + 页面可见性组合触发，反而更可靠、更省电、更兼容。
