如何理解Service Worker注册的任务队列？

先把W3C规范的原文贴出来，方便对照：

Service Worker注册拥有一个或多个任务队列，用于备份其活跃Worker的事件循环对应任务队列中的任务。（该备份操作的目标任务源为handle fetch task source和handle functional event task source。）当活跃Worker终止时，用户代理会将活跃Worker的任务转存至Service Worker注册的任务队列，并将这些任务重新排入活跃Worker的事件循环对应...

这个机制其实是浏览器为Service Worker设计的任务容错保障，核心是解决Service Worker容易被后台终止导致任务丢失的问题，我从几个关键角度帮你拆解：

• 为什么需要这个备份队列？
  Service Worker是浏览器的后台脚本，为了节省内存和CPU，浏览器会在它一段时间没活动时自动终止它。但如果终止时，它还在处理fetch请求（比如缓存页面资源、返回离线响应）或者功能性事件（比如push推送、background sync后台同步），这些任务要是直接丢失，就会影响网站的离线体验、消息推送等核心功能。这个备份队列就是用来“兜底”的。

• 哪些任务会被纳入备份？
  规范里明确限定了范围：只有来自handle fetch task source（处理fetch请求的任务）和handle functional event task source（处理功能性事件的任务，比如push、sync、notificationclick等）的任务才会被备份。像普通的setTimeout定时任务、自定义postMessage消息任务这类，不属于“必须保证完成”的核心任务，所以不会被备份。

• 备份与恢复的完整流程

  1. 实时备份：当Service Worker处于活跃状态时，浏览器会自动把符合条件的任务从它的事件循环任务队列中，同步备份到该Service Worker注册对应的任务队列里——相当于给这些任务存了个“保险副本”。
  2. 终止转存：一旦这个活跃的Service Worker被浏览器终止，浏览器会把它事件循环里还没处理完的符合条件的任务，全部转存到注册的任务队列中。
  3. 任务恢复：等下一次这个Service Worker被激活（比如有新的fetch请求触发，或者浏览器重启它），浏览器会把注册队列里的任务重新排入新实例的事件循环队列，让任务继续执行。

• 本质：任务归属从实例到注册
  这个机制的核心是把任务的“所有权”从单个Service Worker实例，转移到了整个Service Worker注册上。也就是说，只要你的网站完成了Service Worker注册，不管哪个实例在运行，核心任务都会被注册队列托管，不会因为单个实例被干掉而丢失，保证了关键功能的可靠性。

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