Fastify实现IPFS图片流式传输API遇阻及相关疑问

一、流式传输报错的具体解决办法 #

1. Error [ERR_STREAM_WRITE_AFTER_END]: write after end #

这个错就是你在流已经关闭后还尝试写入数据——要么是手动调用了stream.end()后又继续处理数据，要么是IPFS的cat流已经结束但你还在往里面写。
直接这么改：不要手动提前关闭响应流，把IPFS返回的流直接pipe到Fastify的原生响应对象上，Fastify会自动处理流的开启和结束。
示例代码：

app.get('/ipfs-image/:cid', async (request, reply) => {
  const cid = request.params.cid;
  // 给IPFS操作加个超时，避免卡着不动
  const ipfsStream = await ipfs.cat(cid, { timeout: 30000 });
  // 根据图片实际类型设置Content-Type，比如png就改成image/png
  reply.header('Content-Type', 'image/jpeg');
  // 直接pipe到原生响应对象
  ipfsStream.pipe(reply.raw);
});

2. INFO (9617): stream closed prematurely #

这个提示要么是客户端提前断了连接（比如用户刷新页面、切走了），要么是你的流处理逻辑有问题导致连接中断。
处理方式：

• 给IPFS的cat操作加超时时间，避免长时间无响应触发连接关闭；
• 监听流的error事件，捕获异常后只在响应还没发出去的时候返回错误，不然就只打日志：

ipfsStream.on('error', (err) => {
  console.error('IPFS stream error:', err);
  if (!reply.sent) {
    reply.code(500).send('加载IPFS图片失败');
  }
});

3. WARN (14295): response terminated with an error with headers already sent #

这个警告是因为你已经把响应头发给客户端了，之后又想发送错误响应——但此时部分图片数据已经传出去了，没法再改响应了。
解决办法：

• 提前设置好响应头，流出现错误时，只要响应已经发送，就别再尝试发新的响应，只需要记录日志就行，上面的代码已经加了!reply.sent的判断，刚好能处理这种情况。

二、关于流式传输的收益与IPFS加载机制的疑问 #

1. 转为流式传输是否有收益？ #

肯定有，而且收益还不小：

• 省内存：如果是大图片（比如几MB以上），用buffer方式会把整个文件塞进内存，流式传输是分块发，内存占用始终很低，高并发场景下不会因为内存不够崩了；
• 加载更快：客户端不用等整个图片下载完就能开始渲染，用户能更快看到图片加载的过程；
• 防内存溢出：处理超大文件时，buffer方式直接会内存爆掉，流式传输完全没这个问题。

2. IPFS是否已将文件加载到内存中？ #

不一定，看文件大小和IPFS节点的配置：

• 小文件的话，IPFS可能会直接加载到内存缓存，方便下次快速访问；
• 大文件的话，IPFS是分片（block）加载的，只会把当前要传输的分片临时加载到内存，传完就释放，不会把整个文件都塞进内存；
• 用本地IPFS节点的话，流式传输时IPFS会按需从磁盘或者网络拿分片，不会预先把整个文件加载到内存，这也是流式传输能省内存的关键原因之一。

内容的提问来源于stack exchange，提问作者Bill