File System Access API 使用 showSaveFilePicker 保存 Blob 文件

前端已经拿到一个 Blob，想让用户把它保存成文件时，File System Access API 的直接做法是：在 HTTPS 页面里响应用户点击，调用 showSaveFilePicker() 得到 FileSystemFileHandle，再用 createWritable() 写入并关闭流。关闭成功才代表改动提交到目标文件；用户取消、浏览器不支持和写入异常都要单独处理。

官方参考地址：https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker

showSaveFilePicker 负责获得用户授权后的文件句柄

showSaveFilePicker() 不是“直接打开本地任意路径”的接口。它弹出由浏览器管理的保存选择器，只有用户选择或输入文件名后，页面才拿到一个句柄。MDN 将它标为需要安全上下文的实验性能力，因此入口处要同时判断 API 存在和当前页面是否通过 HTTPS 提供。

下面的函数把建议文件名和文件类型交给选择器。types 只影响用户看到的筛选提示，不等于服务端校验；真正保存前仍应在业务层确认 Blob 的内容类型和大小。

async function chooseSaveHandle() {
  // 让调用方在按钮点击期间调用，保留瞬时用户激活状态。
  if (!("showSaveFilePicker" in window)) {
    throw new Error("当前浏览器不支持 File System Access API");
  }

  return window.showSaveFilePicker({
    suggestedName: "export.json",
    types: [{
      description: "JSON 文件",
      accept: { "application/json": [".json"] },
    }],
  });
}

createWritable 写入与关闭决定提交边界

拿到句柄后，创建可写流、写入 Blob、关闭流是最小闭环。createWritable() 常以临时文件承接修改，只有关闭后才把结果替换到目标文件，所以不能在 write() 返回后立即提示“已保存”。发生异常时调用 abort()，避免把未完成内容当成成功结果。

async function saveBlob(handle, blob) {
  const writable = await handle.createWritable({ mode: "exclusive" });
  try {
    // Blob 可以直接交给 WritableStream，避免先拼接成大字符串。
    await writable.write(blob);
    await writable.close(); // 关闭后才把临时内容提交到目标文件。
  } catch (error) {
    // 尽力放弃未完成写入；原始异常仍交给上层展示。
    await writable.abort().catch(() => {});
    throw error;
  }
}

把取消、权限和降级路径写进按钮事件

保存按钮应在点击处理函数里尽快调用选择器。用户点取消通常会得到 AbortError，不应弹出“保存失败”；真正的写入错误才需要提示并记录。下面把三种结果分开，且保留一个不支持 File System Access API 的传统下载兜底。

function downloadFallback(blob, name) {
  // 旧浏览器只能通过临时对象 URL 触发下载。
  const url = URL.createObjectURL(blob);
  const link = document.createElement("a");
  link.href = url;
  link.download = name;
  link.click();
  URL.revokeObjectURL(url); // 下载触发后释放对象 URL。
}

async function onExportClick(blob) {
  try {
    if (!("showSaveFilePicker" in window)) {
      downloadFallback(blob, "export.json");
      return "fallback";
    }
    const handle = await chooseSaveHandle();
    await saveBlob(handle, blob);
    return "saved";
  } catch (error) {
    if (error?.name === "AbortError") return "canceled";
    throw error;
  }
}

exclusive 和 siloed 的选择要看并发写入模型

exclusive 适合应用希望同一文件只允许一个写入者的场景；另一个标签页尝试打开时可能收到 NoModificationAllowedError。默认的 siloed 允许多个写入流各自使用临时副本，最后关闭的写入者可能覆盖先关闭者的结果。它不是冲突合并机制，因此多标签编辑同一文件时仍要在业务层做版本或锁协调。

• 导出按钮只允许单次写入：优先 exclusive，发现占用就提示用户关闭其它编辑窗口。
• 单页应用内不会并发写同一文件：可使用默认模式，但仍应避免重复点击。
• 需要合并修改：不要把 siloed 当作协作锁，应增加版本号、内容摘要或应用级协调。

常见问题

为什么在定时器里调用 showSaveFilePicker 会失败？

它需要瞬时用户激活。把调用放在按钮事件里，再在得到句柄后执行异步写入。

write 成功后可以不调用 close 吗？

不可以把 write 返回当成最终保存。应在成功路径关闭流，异常路径尽力 abort。

这个 API 能否绕过用户授权读取任意文件？

不能。文件句柄来自用户选择，页面也必须满足安全上下文和浏览器权限边界。