HTML怎么做PWA后台同步_HTML PWA Background Sync同步【深度解析】-html教程-PHP中文网

Background Sync 不是注册即触发，必须满足网络在线、Service Worker 持续激活、同步任务未被浏览器丢弃三条件；否则 sync 事件不会触发，常见于非 Chrome/Edge 浏览器、HTTP 环境或未等 ready 就注册。

html怎么做pwa后台同步_html pwa background sync同步【深度解析】

Background Sync 不是“注册了就能自动跑”，它必须满足网络在线 + Service Worker 持续激活 + 同步任务未被浏览器丢弃这三个条件，否则 sync 事件根本不会触发。

为什么调用 `registration.sync.register('my-tag')` 后没反应？

这是最常遇到的卡点。表面上注册成功，但控制台看不到 sync 事件日志，原因往往不是代码写错，而是环境不达标：

SyncManager 只在 Chrome、Edge 和部分 Android WebView 中可用，Firefox 和 Safari 完全不支持 —— 别在这些浏览器里调试
必须在 HTTPS（或 localhost）下运行，HTTP 页面即使注册了也会静默失败
Service Worker 必须处于 active 状态，且不能刚注册完就立刻调用 register()；要等 navigator.serviceWorker.ready Promise resolve 后再操作
浏览器可能因内存压力、后台节流或用户关闭标签页而终止 Service Worker，导致已注册的 tag 被丢弃（getTags() 返回空数组）

`self.addEventListener('sync', ...)` 里能做什么？

这个回调是唯一能安全执行网络请求的离线时机，但它有硬性限制：

不能访问 window、document 或任何 DOM API —— Service Worker 是无窗口环境
必须用 event.waitUntil() 包裹异步逻辑，否则浏览器可能在任务完成前就终止 Worker
不能直接读写 localStorage，得用 IndexedDB 存取待同步数据（比如表单提交内容）
如果 fetch() 失败或 Promise reject，浏览器会按指数退避策略重试（最长可能等数小时），直到成功或标记 lastChance: true

典型写法示例：

self.addEventListener('sync', event => {
  if (event.tag === 'form-submit') {
    event.waitUntil(
      // 从 IndexedDB 读出离线表单数据
      readFromIDB('pending-submissions')
        .then(dataList => Promise.all(
          dataList.map(item => fetch('/api/submit', {
            method: 'POST',
            body: JSON.stringify(item),
            headers: { 'Content-Type': 'application/json' }
          }))
        ))
        .then(() => deleteFromIDB('pending-submissions'))
        .catch(err => console.error('Sync failed:', err))
    );
  }
});

如何可靠地把表单数据塞进后台同步队列？

用户点击提交时，你不能只调用 register() 就完事。得先持久化数据，再注册同步任务，否则页面刷新或崩溃会导致数据丢失：

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

拦截表单 submit 事件，阻止默认提交行为
用 indexedDB.open() 打开数据库，把表单字段存入 object store（如 pending-submissions）
确认写入成功后，再调用 registration.sync.register('form-submit')
为防重复提交，建议在存入 IDB 前生成唯一 id 字段，并在同步成功后用该 id 删除记录

注意：不要在 sync 回调里重新构造表单 DOM 或触发 UI 更新 —— 那些逻辑应该放在主页面监听 message 事件，由 Service Worker 主动 postMessage 通知。

Chrome DevTools 里怎么验证 Background Sync 是否生效？

靠 console.log 很难判断，得用工具链定位真实状态：

打开 Application → Service Workers 面板，勾选 “Update on reload” 和 “Offline”，确保 SW 处于 active 状态
在 Console 里运行 navigator.serviceWorker.ready.then(r => r.sync.getTags())，看返回数组是否包含你注册的 tag
手动触发同步：Application → Service Workers → “Skip waiting” 旁的 “Update on reload”，然后刷新页面，观察是否触发 sync 事件
最关键的验证点：断网后提交表单 → 重新联网 → 等待几秒 → 查看 Network 面板是否有对应 fetch 请求发出

真正容易被忽略的是：Background Sync 的重试机制完全不可控 —— 你无法指定重试次数、间隔或超时时间，只能依赖浏览器策略。如果业务对同步时效性敏感（比如支付确认），得额外加轮询兜底或改用 WebSocket/SSE 实时通道。