GridFS写入超时需调服务端operationTimeout而非客户端socketTimeout；必须用adminCommand动态设置，同步优化chunkSize（推荐1–4MB）和流式上传，并通过uploadId实现中断后精准清理脏数据。
GridFS写入超时根本不是socketTimeout能解决的
直接说结论：socketTimeout 调再大也没用。GridFS上传中途报 Operation timed out after 30000 ms 或 command insert failed: operation exceeded time limit，问题出在 MongoDB 服务端的 operationTimeout 参数，它和客户端的 socketTimeout、connectTimeout 完全无关——前者管整个操作生命周期（比如 chunk 批量写入+元数据更新），后者只管单次 TCP 读/写空闲时间。
你设 socketTimeout: 0 或 600000，只要服务端 30 秒一到就直接 kill 连接，客户端还在等，只会卡住或抛更模糊的 EOF 错误。
必须改服务端 operationTimeout，且只能用 adminCommand
这个参数不能写在 mongod.conf 里，重启不生效，必须运行时动态修改：
- 用有
clusterAdmin权限的账号登录mongosh - 执行：
db.adminCommand({ setParameter: 1, operationTimeout: 300000 })（单位毫秒，这里设为 5 分钟） - 验证是否生效：
db.adminCommand({ getParameter: 1, operationTimeout: 1 })，返回值应匹配你设的数字
注意：该设置全局生效，影响所有 GridFS 操作及其它长耗时命令（如大聚合、建索引），别盲目设成几小时——可能掩盖真实性能瓶颈。
光调超时还不够，chunkSize 和上传方式必须同步优化
单纯拉长超时只是“止痛”，不治本。默认 chunkSizeBytes: 255 * 1024（约 255KB）会导致 GB 级文件生成上万 chunk，fs.chunks 写入压力爆炸，索引更新拖慢整体流程。
- 上传时显式指定
chunkSizeBytes：推荐1048576（1MB）到4194304（4MB），机械硬盘环境优先选 4MB - 必须用流式上传：
bucket.openUploadStream()+pipe()，禁用uploadFromStream()全内存加载，否则 Node.js 进程容易 OOM - 网络极差场景，前端分片（如每片 10MB），后端按
n字段写 chunk，并在metadata中标记status: "uploading"和已传数量，实现断点续传
上传失败后 fs.chunks 里的脏数据怎么清理
GridFS 不支持事务回滚。中断后 fs.files 留着元数据，fs.chunks 堆着半截 chunk，既占空间又干扰查询。
- 最稳妥做法：上传前生成唯一
uploadId（如 UUID），存入metadata.uploadId；失败后直接按该 ID 清理：db.fs.chunks.deleteMany({ "metadata.uploadId": "xxx" })，再删对应fs.files文档 - 若没加
uploadId，可用兜底方案：db.fs.chunks.deleteMany({ files_id: { $nin: db.fs.files.distinct("_id") } })，但需立刻执行db.fs.chunks.reIndex()（MongoDB 4.4+ 支持background: true）
真正容易被忽略的是：上传开始后，fs.files 文档已经写入，但 fs.chunks 可能只写了一部分——这个时间窗口内任何中断都会留下不一致状态，必须靠应用层主动管控，不能依赖驱动或服务端自动修复。
