Fastify中通过流发送IPFS图片报错：stream closed prematurely

问题根源 #

你之前的两种写法都存在不必要的流包装，且破坏了Node.js流的工作机制：

• 第一种写法里，给Readable的read方法用了async/await，但Node.js流的read是同步触发的回调，异步逻辑会打乱流的背压处理，导致Fastify误以为流已经结束，提前关闭响应。
• 第二种写法手动空实现read方法，还漏掉了push(null)来结束流，而且完全没必要自己包装流——ipfs.cat本身就返回标准的Node.js Readable流。

正确实现方式 #

直接使用ipfs.cat返回的流即可，Fastify原生支持处理标准流，会自动管理背压和流生命周期：

const { create } = require('ipfs');
// 全局初始化IPFS实例，不要每次请求都创建，避免资源浪费
const ipfs = create();

fastify.get('/v1/files/:cid', async (request: any, reply: any) => {
  const { cid } = request.params;
  try {
    // 直接获取IPFS返回的流
    const ipfsStream = ipfs.cat(cid);
    
    // 可选：动态获取文件MIME类型，替代固定的image/png
    // const fileStat = await ipfs.files.stat(`/ipfs/${cid}`);
    // reply.type(fileStat.mimeType || 'image/png');
    
    reply.type('image/png').send(ipfsStream);
  } catch (error) {
    // 处理IPFS读取失败的情况，比如CID不存在
    reply.code(404).send({ error: 'Failed to fetch file from IPFS' });
  }
});

关键注意事项 #

1. 全局IPFS实例：不要在每个请求里调用create()，重复创建IPFS节点会消耗大量内存和网络资源，全局初始化一次即可。
2. 错误处理：添加try/catch捕获IPFS操作的异常，返回合适的HTTP状态码，避免请求挂起或返回模糊的错误。
3. 动态Content-Type：如果需要支持多种文件类型，用ipfs.files.stat获取文件的MIME类型，替代固定的image/png，提升兼容性。

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