这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 Service Worker 随时会被终止，且无法长期持有页面的 RTCPeerConnection 或用户选取文件句柄。Background Sync 适合短、幂等、可重建请求。
离线体验必须诚实区分本地可用、等待同步和服务端已确认。缓存版本、命令队列和冲突解决要一起设计，否则重新联网只会放大旧操作与新事实的冲突。
先把实现决策说清楚
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 仅排队小事件和分析批次，任务有 idempotency key、重试上限和过期；大文件保存 resume metadata 并在用户回到前台后重新授权继续。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“Background Sync 的边界：不能拿它承诺大文件一定会后台传完”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 把文件 Blob 全塞 IndexedDB 等后台同步会吃满配额；界面承诺“可关页面”但浏览器不支持会直接丢失用户信任。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 没有背压或配额时，慢消费者会把内存、队列长度与尾延迟一起推高，最后拖累无关用户。
上线前怎样验证
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 在不支持、系统拒绝、Worker 中途终止、离线数天和请求永久 4xx 下测试，队列应收敛且大文件文案不作虚假承诺。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。