Workbox V6 BackgroundSync离线修改元素UI更新及刷新回退问题求助

核心原因：Workbox V6的BackgroundSync功能，会把离线状态下失败的更新请求存在Service Worker专属的IndexedDB存储空间里，这块存储的访问权限由Service Worker管控，前端业务页面没有办法直接读取，也就感知不到本地还有待发送的修改操作。当用户离线修改输入框再刷新页面时，前端会重新拉取服务端的元素初始值，因为不知道本地待同步的修改内容，自然就会回退到修改前的旧状态。

• 业务侧独立存储待同步的修改信息，和Service Worker的队列做映射
  不要完全依赖Service Worker内部的BackgroundSync队列存储所有离线修改数据。在前端拦截用户对元素的修改操作时，同步把关联元素ID、用户输入的修改值、目标接口地址、请求方法、请求体等信息，存到前端可以直接读写的普通IndexedDB里。
  每条存储记录要绑定当前使用的BackgroundSync队列标识（也就是你代码里的offlineSyncQueue），标记同步状态为pending，和Service Worker内部的重试队列做一一对应，绕开SW存储的权限隔离问题。
• 改造页面初始化的渲染逻辑
  页面加载获取元素初始数据的时候，不要直接把接口返回的旧值渲染出来，先从业务侧的IndexedDB里查询所有属于offlineSyncQueue队列、状态为pending的修改记录。
  按元素ID做匹配校验，用本地存的待同步修改值覆盖接口返回的旧值，再渲染到对应输入框上，这样哪怕离线刷新页面，只要待同步请求还在队列里，UI就会一直显示用户未发送的修改内容，不会回退到旧状态。
• 打通Service Worker和前端的状态同步链路
  通过Workbox的同步事件回调，监听BackgroundSync队列的请求执行结果：当队列里的修改请求发送成功、拿到服务端的成功响应后，用postMessage给前端页面发送同步完成的通知，前端接收到通知后，把业务侧IndexedDB里对应的pending修改记录标记为已完成或者直接删掉，保证UI状态和服务端数据一致。
  如果请求同步失败，就保留对应的pending记录，等下次网络恢复继续重试，避免出现状态错乱。

你当前的Service Worker配置有两个容易引发状态不一致的隐患：

• 代码里设置的maxRetentionTime: 0.1 * 60折算下来只有6分钟，留存时长太短，弱网场景下请求可能还没等成功发出去就被队列自动清除，会导致本地一直显示用户的离线修改值，但实际重试请求已经丢失，建议根据业务场景调整到合理的长效留存值。
• 现在所有匹配http://localhost:3001/的路由都统一套NetworkFirst策略+BackgroundSync插件，没有区分GET查询接口和POST/PUT更新接口的差异，容易出现更新请求被错误缓存、和离线同步逻辑冲突的问题。建议把更新类的修改接口单独注册路由，匹配独立的处理策略，和查询接口做逻辑隔离。

内容的提问来源于stack exchange，提问作者Keren