HTML本身无法实现静默推送，真正可行的是Push API+Service Worker方案：需HTTPS、用户授权通知权限、服务端通过FCM等发送轻量推送，SW在页面关闭后仍可接收并缓存数据，但业务数据需页面激活后拉取。
HTML 本身做不到静默推送数据更新——它没有后台运行能力，也不支持常驻连接。所谓“HTML 静默推送”，实际是前端配合服务端、借助浏览器提供的特定 API（如 Service Worker + Push API）实现的“看起来静默”的更新行为，且仅限 HTTPS 环境、仅限支持 PWA 的现代浏览器（Chrome、Edge、Firefox 桌面端基本可用，Safari 仍不支持 Push API）。
为什么 fetch() 或 XMLHttpRequest 不算静默推送
它们必须由页面主动发起，页面关闭或切到后台后，多数浏览器会节流甚至中止定时请求；即使设成 setInterval，也依赖标签页活跃状态，无法在用户完全离开时触发更新。这不是“推送”，只是轮询，且容易被系统休眠、浏览器冻结机制打断。
常见错误现象：fetch() 在后台标签页中突然停止响应、setTimeout 延迟严重、安卓 Chrome 后台标签页 5 分钟后自动暂停 JS 执行。
- 轮询无法保证实时性，延迟从几秒到几分钟不等
- 无用户交互时，浏览器可能直接冻结 fetch 请求（尤其移动端）
- 频繁轮询增加服务端压力，且浪费客户端电量
真正可行的静默更新路径：Push API + Service Worker
这是目前唯一被浏览器原生支持的、能在页面关闭后仍接收服务端指令并执行逻辑的方案。但注意：它不传输业务数据，只发一个轻量通知（最多 4KB payload），真实数据仍需页面激活后主动拉取。
立即学习“前端免费学习笔记（深入）”；
使用场景：消息提醒、订单状态变更、配置热更新（比如灰度开关）、离线内容预加载。
- 必须部署在 HTTPS 环境（localhost 除外）
- 需注册
Service Worker并完成push事件监听 - 服务端需调用第三方推送服务（如 Firebase Cloud Messaging / Web Push Protocol 兼容服务）发送加密 push 消息
- 用户必须已授予
Notifications权限（否则 push 无法送达）
示例片段（Service Worker 中）：
self.addEventListener('push', event => {
const data = event.data?.json() || {};
// 这里不能直接操作 DOM，但可缓存数据、发 postMessage 给页面、或调用 clients.matchAll()
event.waitUntil(
caches.open('api-cache').then(cache => cache.put('/api/status', new Response(JSON.stringify(data))))
);
});
Service Worker 更新失败的三个高频坑
很多“静默推送”卡在 SW 自身没更新，导致新 push 事件根本没监听器。
-
navigator.serviceWorker.register()调用后未检查返回 promise 是否 resolve，误以为注册成功（实际可能因路径、HTTPS、404 导致失败） - 修改了 SW 文件内容但没触发浏览器重新下载——需手动
navigator.serviceWorker.getRegistration().then(r => r.update())或等待 24 小时自动检查（默认策略） - SW 中写死
cacheName，更新后未清理旧缓存，导致 fetch 事件命中旧缓存而拿不到新数据
验证是否生效：打开 Chrome DevTools → Application → Service Workers，看状态是否为 “activated and is running”，点击 “Update on reload” 强制刷新注册。
真正的难点不在代码，而在权限链和生命周期控制：用户授权通知、SW 激活时机、页面与 SW 的通信时机、后台消息到达后如何唤醒页面逻辑——这些环节任意一个断开，“静默”就变成“无声无息”。
