根本不是文件太大，而是客户端和服务端双重超时在传输中途主动掐断连接：PyMongo默认serverSelectionTimeoutMS=30000（30秒）与服务端operationTimeout硬编码值同时生效，4GB文件上传需3–8分钟，远超阈值；必须显式设serverSelectionTimeoutMS≥600000（10分钟），并同步调大socketTimeoutMS、connectTimeoutMS及服务端operationTimeout，且GridFS应增大chunkSizeBytes至4MB以减少分块数量和BSON解析开销。
根本不是文件太大，而是客户端和服务端双重超时在传输中途主动掐断了连接——默认30秒的 serverSelectionTimeoutMS 和服务端硬编码的 operationTimeout 同时生效，上传还没完成就被清理了。
Python pymongo 里 GridFS.put() 卡住或抛 TimeoutError
这不是网络问题，是驱动默认启用了 Client Side Operation Timeout（CSOT），且值仅30秒。4GB文件在千兆内网通常需3–8分钟上传，远超该阈值。
-
socketTimeoutMS和connectTimeoutMS不管用：它们只控制单次读写或建连空闲，不覆盖整个上传生命周期 - 必须显式设置
serverSelectionTimeoutMS=600000（10分钟）及以上，这是 CSOT 的入口参数 - 连接字符串里加
timeoutMS=600000是无效的，pymongo 4.0+ 已弃用该参数 - 示例正确写法：
client = MongoClient("mongodb://localhost", serverSelectionTimeoutMS=600000, socketTimeoutMS=600000, connectTimeoutMS=30000)
Java Spring Boot 中 GridFsTemplate 上传失败报 Read timed out
Spring Data MongoDB 的 GridFsTemplate 底层复用 MongoClient 配置，但容易忽略两点：一是未启用 CSOT，二是未同步调大服务端 operationTimeout。
- Java 驱动需通过
MongoClientSettings显式配置超时，不能只改SocketSettings - 关键配置项：
maxConnectionLifeTimeMS、maxConnectionIdleTimeMS也要拉长，否则连接池提前回收流 - 服务端必须同步执行：
db.adminCommand({ setParameter: 1, operationTimeout: 600000 })，否则客户端等再久也没用 - Spring Boot application.yml 中仅配
spring.data.mongodb.socket-timeout=60000不足以解决问题
Node.js 驱动上传中断后 fs.chunks 留下大量孤儿 chunk
上传失败不等于什么都没写——GridFS 默认分块大小为 255KB，4GB 文件会生成约 16,000 个 fs.chunks 文档。中断时可能已写入前几千个，但 fs.files 还没落库，形成“有 chunk 无 file”的脏数据。
- 不要依赖自动索引：确认
db.fs.chunks.createIndex({ "files_id": 1 })已存在，否则后续清理查询极慢 - 上传前务必注入唯一
uploadId到metadata，如：{ uploadId: "uuid-v4-here" } - 失败后清理命令必须两步：
db.fs.chunks.deleteMany({ "metadata.uploadId": "xxx" })→ 再删对应fs.files文档 - 别用
bucket.delete()清理：它只删fs.files和关联chunks，但前提是files存在；中断后该文档往往不存在
为什么调大 chunkSizeBytes 能缓解超时和 CPU 压力
默认 255KB 分块不是为大文件设计的。4GB 文件切出上万个 chunk，不仅放大写入次数、拖慢磁盘 IO，还让驱动反复解析 BSON 文档头、拼接 buffer，CPU 和网络开销双双飙升。
- 推荐设为
chunkSizeBytes: 4194304（4MB）：chunk 数量降至约 1,000，显著减少 BSON 解析和索引更新压力 - 注意单位：传数字，别传字符串如
"4MB"，驱动会静默忽略 - 机械硬盘环境尤其敏感：iostat 显示
w/s高但wkB/s低，基本就是小块随机写瓶颈 - 别盲目设成 8KB 或 64KB：chunk 越小，驱动内部 pending write 队列越长，GC 压力反而上升
真正卡住你的，往往是服务端 operationTimeout 和客户端 CSOT 不匹配、chunkSize 未适配硬件、以及上传失败后没做 uploadId 标记——这三处不处理，光加超时只是把失败从30秒延到60秒而已。
