不能直接用res.send(gridfsStream)，因为Express不自动识别ReadableStream为二进制内容，必须手动设置Content-Type和Content-Length响应头，否则浏览器无法正确解析或卡在加载状态。
直接用 GridFSBucket 的 openDownloadStream 返回流，再 pipe 给响应对象即可，但必须手动设置 Content-Type 和 Content-Length，否则浏览器无法正确渲染图片。
为什么不能直接 res.send(gridfsStream)？
Express 默认把流当作普通 body 处理，不设 Content-Type 时会 fallback 到 text/plain；没传 Content-Length 或没启用 chunked encoding，部分客户端（尤其是 iOS Safari）会卡在 loading 状态或报 net::ERR_INCOMPLETE_CHUNKED_ENCODING。
-
openDownloadStream返回的是ReadableStream，不是 Buffer，不能被res.send自动识别为二进制内容 - GridFS 文件元数据里存了
contentType，但 Express 不会自动读取并设置响应头 -
length字段在files集合里，需显式查出或从 stream 的metadata中获取（取决于你写入时是否存了）
如何安全获取文件 ID 并打开流？
用 ObjectId 解析请求参数，失败就 400；再用 findOne 查 files 集合确认文件存在且有 contentType，避免空流或类型错误。
- 别用字符串拼接 ID：
new ObjectId(req.params.id)，捕获ObjectId.isValid()和构造异常 - 查
files集合比直接开流更稳妥——openDownloadStream找不到文件会触发error事件，但此时响应头可能已发，导致 unhandled error - 优先从
files文档的contentType字段取 MIME 类型，fallback 到path.extname解析不靠谱（GridFS 不强制存扩展名）
流式返回时怎么设响应头？
必须在 pipe 前设置 Content-Type 和 Content-Length，且顺序不能错：先 res.writeHead 或 res.setHeader，再 stream.pipe(res)。
-
Content-Length推荐从files文档的length字段读，它是精确字节数；别用stream.readableLength（Node.js 16+ 才有，且是缓冲区估算值） - 如果文件很大（>100MB），加
res.flushHeaders()可提前发 header，避免客户端长时间等待 - 加
res.on('error', () => stream.destroy())防止连接中断后 stream 泄漏
最易被忽略的是 files 集合查询和 Content-Length 的来源——很多人图省事直接开流、靠 error 处理不存在文件，结果线上偶发 500 或图片显示为损坏图标；而 length 字段一旦为空（比如旧数据没写全），就会让浏览器一直转圈。
