多个用户读同一文件不会互相阻塞，因为gridfs的opendownloadstream()返回独立readablestream，各流封装独立chunk查询与校验，驱动通过连接池和异步i/o实现并发隔离，fs.files仅读元数据，chunk按需读取且无文件级锁定。
GridFS 本身支持多用户同时下载同一文件，无需额外改造——只要每个请求都走独立的 openDownloadStream()，底层驱动会自动处理并发读取、chunk 缓存和连接复用。真正要防的是误操作导致的资源争抢或流泄漏。
为什么多个用户读同一个文件不会互相阻塞
GridFS 的 openDownloadStream() 返回的是独立的 ReadableStream，每个流内部封装了自己的一组 chunk 查询逻辑和校验流程。MongoDB 驱动（v5+）在底层使用连接池和异步 I/O，不同请求即使查同一个 _id，也会走不同的 socket 请求或复用空闲连接，互不干扰。
- fs.files 文档只读一次（用于获取元数据），后续 chunk 读取按需发起，不锁定文件
- 每个流有自己的 buffer 和背压控制，不会因某个慢客户端拖垮其他流
- 驱动默认启用
maxPoolSize（通常 100），足够应对常规并发下载
常见踩坑：看似“同一文件”，实则触发非预期行为
你以为用户都在下 report.pdf，但实际可能命中不同文件——尤其当业务层用 filename 查而非 _id 时。
-
downloadToStreamByName('report.pdf')默认取revision: -1（最新版），但如果上传频繁，不同请求可能拿到不同版本，导致用户下载内容不一致 - 若未显式指定
revision，且存在同名文件，find({ filename: 'report.pdf' })可能返回多个文档，驱动取第一个（非确定性） - 用
bucket.find({ filename: ... }).toArray()再手动选一个，不如直接用_id精准定位，避免歧义
高并发下需主动控制的三个点
单个文件被上百人同时下载时，问题不出在 GridFS，而出在 Node.js 进程、MongoDB 连接池或网络带宽。必须干预的环节：
-
限制单个请求的流并发数：即使只下 1 个文件，如果前端分片请求（如 Range 下载），每个分片都会调
openDownloadStream()，建议用p-limit控制同时打开的流 ≤ 5 -
显式销毁失败流：某次
openDownloadStream()报错（如MongoServerError: File not found），必须stream.destroy()，否则残留流会占用内存和连接 -
避免响应体超时中断：大文件下载耗时长，Nginx 或负载均衡器默认 60s 超时，需调高
proxy_read_timeout或加心跳（如定期 write 0 字节）
真正难的不是“能不能并发下载”，而是确保每个请求的流生命周期干净、错误可捕获、资源不堆积。尤其当用户关浏览器或网络中断时，Node.js 不会自动 cleanup 流，得靠 req.on('close', () => stream.destroy()) 补漏。
