好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 OPFS 给站点提供私有文件系统并支持高效随机写，适合稀疏分块与超大临时文件；它不是用户可见下载目录，站点数据清除后内容也会消失。
浏览器能力由版本、权限、页面可见性和设备策略共同决定。实现需要能力探测与可解释降级，不能把某一台开发机上的 API 存在当成产品契约。
先定义系统契约
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 在专用 Worker 中使用同步访问句柄，主线程只接收进度与状态。
- manifest 保存逻辑文件大小与已写区间，文件长度不能代替完整性记录。
- 能力检测失败时降级 IndexedDB，并对两种后端保持相同任务协议。
OPFS 是高性能临时后端，不是永久承诺。只有兼容降级、manifest 证据、导出流程和清理策略齐全时才适合大文件。
哪些情况会破坏契约
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 多个 Worker 同时打开同一同步句柄，锁冲突导致任务永久等待。
- 接收完成后忘记导出或提示保存，文件只留在站点私有空间。
- 取消与过期任务不删除 OPFS 文件，长期积累敏感内容和配额占用。
如何逐条验证契约
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 随机顺序写入、刷新再读回，验证稀疏区间和最终摘要一致。
- 模拟句柄锁竞争、Worker 崩溃和配额耗尽，确认任务可重试或清理。
- 完成、取消、过期和清除站点数据后分别检查文件生命周期与用户提示。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。