db.currentOp() 查不到 GridFS 下载连接，因其被拆为多个 find 操作（查 fs.files 和 fs.chunks），无 gridfs 标识；需通过 secs_running、client、ns 等字段结合 netstat 才能准确定位泄漏。
db.currentOp() 为什么查不到 GridFS 下载连接
因为 GridFS 下载在 MongoDB 层面不表现为单个“GridFS 操作”，而是拆成多个 find 查询：先查 fs.files 拿元数据，再按 files_id 和 n 顺序查 fs.chunks。这些操作在 currentOp() 中显示为普通 find 或 getMore，没有 gridfs 字样，直接过滤容易漏掉。
真正有效的过滤方式是盯住耗时和命令结构：
- 用
db.currentOp({ "secs_running": { "$gt": 30 }, "command.find": { "$exists": true } })抓长期运行的 find 查询 - 重点看返回结果里的
client字段——同一 IP+端口反复出现，基本就是某个下载流没关干净 - 检查
ns字段是否为fs.files或fs.chunks，确认确实是 GridFS 相关查询
如何从 currentOp 输出识别泄漏源头
currentOp() 返回的每个操作里，client、secs_running、microsecs_running 和 active 是关键字段。泄漏连接通常表现为：
-
active: true且secs_running > 60，但客户端早已断开（比如 HTTP 请求超时或关闭） -
client值重复出现多次，尤其来自同一个应用实例的 IP:port 组合 -
query字段里有files_id和n条件，但n值跨度大（如从 0 查到 128），说明正在读大文件且卡在中间
注意：currentOp() 只反映“当前活跃操作”，不包含已结束但连接未释放的情况——这类问题必须配合 netstat -anp | grep :27017 | grep ESTABLISHED 看真实连接数才能确认。
currentOp() 配合 netstat 定位真实泄漏点
只看 currentOp() 容易误判：比如连接池满导致新请求排队，看起来像“很多慢查询”，实际是下游阻塞。必须交叉验证：
- 执行
db.currentOp({ "secs_running": { "$gt": 30 } })得到活跃操作列表 - 同时跑
netstat -anp | grep :27017 | grep ESTABLISHED | wc -l，对比结果是否远超应用配置的maxPoolSize - 如果 netstat 连接数持续高于池子上限（比如池设 50，netstat 显示 120+），基本可断定是流未关闭导致连接泄漏
- 对 netstat 输出做
awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10，找出连接最多的客户端 IP
currentOp() 查到泄漏后怎么修代码
查到具体 client 和耗时操作后，回到对应服务代码，重点检查 GridFSBucket.openDownloadStream() 的调用路径：
- Node.js：确保
stream有end和error监听，并调用destroy()，不能只依赖pipe()——例如stream.on('end', () => stream.destroy()) - Python：必须用
with语句或显式close()，避免在异常分支里跳过销毁逻辑 - Java：
GridFSDownloadStream.close()必须放在finally块，不要只靠 try-with-resources（某些驱动版本在 IO 异常时会跳过资源释放） - 所有语言：检查是否把流直接 pipe 到慢速下游（如未压缩的大文件响应体），考虑加
setTimeout()或分块读取后主动destroy()
驱动版本也很关键：旧版（如 Node.js Driver v3.x、Java Driver maxPoolSize 是否足够，否则一个泄漏连接就能拖垮整个池。
