这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 文件句柄可以存进 IndexedDB，但权限可能在会话、浏览器或系统策略变化后回到 prompt。恢复任务时必须重新查询权限，并在用户动作中请求，不能把保存句柄描述成后台永久访问。
浏览器能力由版本、权限、页面可见性和设备策略共同决定。实现需要能力探测与可解释降级，不能把某一台开发机上的 API 存在当成产品契约。
先把实现决策说清楚
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 句柄仅与具体任务和本地设备绑定，不通过信令或分析上传序列化信息。
- 重新打开后比较文件大小、修改时间和内容摘要，句柄指向文件也可能被替换。
- 不支持 API 或权限拒绝时退回普通文件选择器，并保留已接收进度。
句柄改善的是重选体验，不改变用户控制权。每次恢复都重新确认权限与内容身份，产品承诺才与浏览器边界一致。
最容易漏掉的失败路径
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 启动时自动 requestPermission，不在用户动作里调用导致浏览器拒绝。
- 句柄仍有效就跳过摘要，用户覆盖源文件后把新内容续进旧任务。
- UI 显示“永久访问”，用户无法理解撤权后为何任务突然失败。
上线前怎样验证
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 授权、拒绝、撤销、文件移动和内容覆盖后分别恢复同一任务。
- Chrome 能力路径与其他浏览器普通选择路径跑相同完整性用例。
- 检查导出数据、日志和同步记录，确保不包含句柄、真实路径或权限细节。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。