structuredClone() 无法拷贝 FileSystemHandle 对象，会抛出 DataCloneError 异常；因其权限状态不可序列化，应通过 postMessage 传递引用或重新获取 handle。

不能通过 structuredClone() 拷贝具备原始权限的 FileSystemHandle 对象。

FileSystemHandle 不可被 structuredClone() 序列化

FileSystemHandle（包括 FileSystemFileHandle 和 FileSystemDirectoryHandle）是受权限约束的宿主对象，其内部状态（如底层文件系统访问令牌、权限上下文）无法被结构化克隆算法捕获。调用 structuredClone(handle) 会直接抛出 DataCloneError 异常。

• 浏览器明确将 FileSystemHandle 列为 structured clone 算法不支持的类型
• 即使 handle 已经获得用户授权（例如通过 showOpenFilePicker()），它仍不具备可序列化的权限凭证
• 克隆操作仅适用于纯数据对象（如 plain objects、arrays、Map、Set、Date、RegExp 等），不延伸至绑定操作系统资源的接口实例

替代方案：传递引用或重新获取 handle

若需在不同上下文（如主线程 ↔ Worker、iframe 间）使用同一文件句柄，应避免拷贝，改用以下方式：

• 跨线程共享引用：通过 postMessage() 直接传递 handle（现代浏览器支持将其作为 transferable 发送，无需克隆）
• 持久化权限后重新获取：调用 navigator.storage.getDirectory() 或使用 handle.resolve() + getDirectoryHandle() 等方法，在目标环境中基于已知路径重建访问链
• 存储并复用权限令牌：对已授权的 handle，可调用 self.showDirectoryPicker({id: 'my-app-root'}) 配合 id 参数实现“记住位置”，后续用相同 id 调用 showDirectoryPicker() 可静默返回已有权限的 handle

注意权限作用域与生命周期

FileSystem API 的权限与具体 origin、top-level browsing context 及用户显式交互强绑定：

• handle 本身不携带可导出的“权限密钥”，无法脱离创建它的页面环境复用
• 关闭标签页或刷新后，未持久化的 handle 将失效；需调用 requestPermission() 或再次触发 picker 才能恢复访问
• Worker 中无法直接调用 showOpenFilePicker()，必须由主线程获取 handle 后传入

不复杂但容易忽略：handle 是活的权限代理，不是静态数据——设计时应围绕“传递”和“重获”构建流程，而非尝试复制它。