PeriodicBackgroundSync 已被彻底废弃，Chrome 90+ 移除、Firefox/Safari 从未支持，调用会报 TypeError；替代方案是用 BackgroundSync 事件配合时间戳缓存实现机会型定期同步。
PeriodicBackgroundSync 已不可用。Chrome 90+ 彻底移除，Firefox 和 Safari 从未支持，W3C 规范标记为 “Inactive”。任何调用 navigator.periodicSync.register() 的代码都会报 TypeError: navigator.periodicSync is undefined，不是兼容性问题，而是 API 已被废弃。
为什么 periodicSync 在控制台直接报错
这不是环境没配好，也不是权限没开——是浏览器根本不再提供这个对象。Chrome 自 2021 年起逐步下线实验性实现，90 版本后完全删除；Edge 同步跟进；其余主流浏览器从未实现。你看到的旧教程、MDN 快照或 Stack Overflow 示例，基本都来自 2020–2021 年实验阶段，现在复制粘贴必失败。
-
navigator.periodicSync永远为undefined，哪怕 HTTPS、PWA 安装态、通知权限全满足 - Service Worker 文件里写
self.addEventListener('periodicsync', ...)不会触发，也不会报错，只是静默忽略 - 试图用
registration.periodicSync.getTags()查已注册任务？该方法不存在，调用即TypeError
替代方案：用 sync 事件 + 时间判断模拟“定期”
BackgroundSync 本身不支持定时，但它在网络恢复时触发，配合本地时间缓存，可实现“机会型定期同步”——只要用户有联网行为（开网页、切回标签、重连 Wi-Fi），就检查是否超时并执行一次。
- 在 Service Worker 中监听
sync事件，而非已不存在的periodicsync - 用
caches存上一次同步时间戳（不能用localStorage，SW 里不可访问） - 每次触发时计算
Date.now() - lastSyncTime，大于设定间隔（如24 * 60 * 60 * 1000）才真正 fetch - 同步成功后，必须再写入新时间戳，否则下次仍会立即触发
示例关键片段：
立即学习“前端免费学习笔记（深入）”；
self.addEventListener('sync', async (event) => {
if (event.tag === 'daily-news-fetch') {
const cache = await caches.open('meta');
const lastResp = await cache.match('/last-sync');
const lastTime = lastResp ? parseInt(await lastResp.text()) : 0;
const now = Date.now();
const interval = 24 * 60 * 60 * 1000;
if (now - lastTime >= interval) {
event.waitUntil(
fetch('/api/news').then(r => r.json())
.then(data => caches.open('news').then(c => c.put('/latest', new Response(JSON.stringify(data)))))
.then(() => cache.put('/last-sync', new Response(now.toString())))
);
}
}
});真要“每天凌晨 2 点执行”，前端做不到
浏览器禁止无用户交互的后台定时唤醒。所有前端方案（setInterval、Worker、BackgroundSync）都受制于标签页生命周期：页面关闭、系统休眠、Chrome 后台节流，都会中断执行。所谓“定时”，实际是依赖用户行为触发的补偿机制。
-
setInterval在非活跃标签页中会被严重降频（5 秒变 1 分钟甚至更久），且页面关闭即销毁 - 单独起
Worker执行轮询，仍无法绕过标签页关闭或浏览器内存回收 - 唯一可靠的方式是后端调度：用 Node.js/Python 跑 cron 任务，通过 Push API 主动唤醒 Service Worker（需用户授权通知）
- Push 方案虽可行，但需额外服务端支持、HTTPS、用户显式授权，且 Firefox/Safari 对 Push 支持有限
真正难的不是写几行注册代码，而是接受浏览器对后台行为的严格限制——它不让你“定时”，只给你“机会”。所有替代方案都要围绕“用户什么时候可能在线”来设计，而不是盯着时钟。
