FileSystemWritableFileStream.write方法性能问题及相关实现疑问

我来帮你拆解这个问题，先从你关心的临时文件机制说起，再聊聊性能慢的原因和优化方向：

关于临时文件的核心疑问 #

你理解的完全没错——FileSystemWritableFileStream.write()确实会先将内容写入临时文件，直到你调用close()方法，浏览器才会把临时文件原子性地替换成目标文件。这是浏览器为了保证文件写入的原子性设计的：如果写入中途失败（比如网络断开、浏览器崩溃），目标文件不会变成损坏的状态，只会保留原来的内容（如果是新建文件就不会创建）。

你的两个具体问题解答 #

1. 临时文件的位置：
   这个是浏览器内部沙箱化管理的，不同浏览器的存储路径不一样，而且你无法直接访问或配置它。比如Chrome会把这类临时文件存在其用户数据目录下的隔离分区中，完全由浏览器管控，开发者没有干预权限。

2. 能否直接写入目标文件？
   很遗憾，目前Web File System API没有提供跳过临时文件的选项，因为原子写入是这个API的核心设计之一，用来保障数据完整性。不过我们可以通过优化写入方式，大幅提升复制速度，接近手动复制的水平。

为什么你的代码比手动复制慢这么多？ #

你遇到的速度差异，主要有两个核心原因：

• 一次性写入整个文件：你当前的代码是直接把整个File对象传给write()，浏览器需要先将整个大文件加载到内存（或内存缓存），再写入临时文件，最后还要把临时文件完整上传到NFS共享。而手动复制（Ctrl+C/V）是系统级操作，会用更高效的分块传输，甚至能利用操作系统的零拷贝技术（直接将磁盘数据传到网络，不需要经过用户态内存中转）。
• 临时文件的二次传输成本：如果临时文件存在本地磁盘，调用close()时的“移动”操作，对于NFS这类网络共享来说，本质是把整个临时文件再上传一次，相当于多了一轮完整的文件传输，这是速度慢的关键！

优化方案：流式分块写入 #

你之前尝试的pipeTo是完全正确的方向，通过流式分块处理，我们可以避免一次性加载整个文件到内存，还能让数据边读边写，减少中转开销。优化后的代码如下：

// Source file
const file = await fileHandle.getFile();
// Destination
const fileDestination = await location.getFileHandle(file.name, { create: true });

const writable = await fileDestination.createWritable();
try {
  // 流式分块传输：边读取源文件边写入目标流
  await file.stream().pipeTo(writable, { preventClose: true });
  await writable.close();
} catch (e) {
  console.error(e);
  // 出错时终止写入，清理临时文件
  await writable.abort();
}

优化点说明 #

• 流式传输：file.stream()会生成一个可读流，pipeTo会自动将流中的数据分块传输到可写流，每处理完一块就写入临时文件，不需要等待整个文件加载完成。
• 内存友好：对于200GB的超大文件，这种方式不会导致内存溢出，因为每次只处理一小段数据。
• 接近系统级效率：虽然浏览器还是会用临时文件，但流式分块可以减少内存中转的开销，让写入速度大幅提升，接近手动复制的水平。

额外提示 #

不同浏览器的File System API实现略有差异，比如Chrome和Firefox的临时文件管理、分块大小策略可能不同，你可以多测试几个主流浏览器，找到最适合你场景的方案。

备注：内容来源于stack exchange，提问作者Triet Doan