浏览器崩溃后清理localStorage孤儿进程ID及多标签队列适配咨询

一、Service Worker 是可行的解决方向 #

Service Worker独立于页面运行，不会因为标签崩溃或刷新停止工作，刚好能解决你的孤儿ID问题：

• 把队列的管理逻辑移到Service Worker：所有标签的流程注册、状态同步都通过Service Worker完成，不再直接操作localStorage。每个流程启动时向Service Worker注册ID，上传过程中每隔几秒发一次心跳。
• Service Worker维护带心跳时间的队列：每个队列项存process ID和最后心跳时间，每隔10秒左右扫描一次队列，把超过30秒没发心跳的ID直接移除——这些就是崩溃标签留下的孤儿ID。
• 标签只需要向Service Worker查询：每秒检查一次自己的ID是不是队首且状态有效，是就继续上传，传完文件通知Service Worker更新队列。

这样不管哪个标签崩溃，Service Worker都会自动清理失效ID，不会阻塞后续流程。

二、纯客户端优化方案（不用Service Worker） #

如果暂时不想引入Service Worker，可以先优化localStorage的队列结构：

• 给每个队列ID加超时时间戳：新增流程时，除了ID，还要存当前时间+超时阈值（比如5分钟）。
• 每次检查队列前先清理超时项：setInterval触发时，先过滤掉时间戳早于当前时间的ID，再判断队首是不是自己的ID。
• 上传过程中更新时间戳：每传100个文件就更新一次当前ID的时间戳，避免正常上传时被误清理。

不过这个方案有局限：如果所有标签都关了，失效ID要等下次打开页面才会被清理，没法实时处理，但比原方案强很多。

三、前后端结合才是最可靠的方案 #

客户端方案都有各自的限制（比如Service Worker需要HTTPS，纯客户端没法实时清理），对于10万量级的大文件上传，更建议用前后端结合的方式：

• 后端维护全局上传队列：把原来存在localStorage的process IDs移到后端数据库，每个流程启动时向后端注册，获取队列位置。
• 前端加心跳上报：上传过程中每隔10秒向后端发一次心跳，后端记录每个流程的最后活跃时间。
• 后端自动清理失效流程：定时扫描队列，把超过阈值没心跳的ID移除。
• 前端从后端查队列状态：每秒向后端请求，确认自己的ID是不是队首且有效，是就继续上传，传完文件通知后端更新队列。

这种方案完全不受客户端崩溃、多标签的影响，后端还能统一监控所有上传流程的进度，更适合大规模文件上传的场景。

四、额外优化建议 #

• 断点续传：把已上传的文件索引存在IndexedDB里，页面恢复后可以从断点继续传，不用从头开始。
• 队列操作同步：多标签同时操作队列时，用localStorage的storage事件做同步，避免多个标签同时改队列导致数据乱掉。

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