GridFS上传超时需修改服务端operationTimeout参数而非客户端socketTimeout，因前者控制整个操作生命周期，后者仅影响单次TCP读写；须用adminCommand动态设置并确保客户端流式上传。
GridFS上传超时不是靠调客户端socketTimeout能解决的，根本得改服务端operationTimeout参数——否则你设成0也没用，30秒一到MongoDB直接杀掉操作，客户端还在等，结果就是卡死或抛EOF错误。
为什么socketTimeout调大没用？
因为GridFS上传是复合操作：要写多个chunks文档、再更新files元数据文档。客户端socketTimeout只管单次TCP读写空闲时间，而服务端operationTimeout才控制整个操作生命周期（含批量写+事务协调）。两者完全不交叉。
- 现象：
Operation timed out after 30000 ms或command insert failed: operation exceeded time limit - 误区：在
MongoClientSettings里狂加socketTimeout、connectTimeout - 真相：这些参数对GridFS上传耗时无实质影响，只是让客户端“等得更久”，但服务端该超时还是超时
必须用adminCommand动态改operationTimeout
这个参数不能写进mongod.conf，重启也不生效，只能运行时修改：
- 用有
clusterAdmin权限的账号登录mongosh - 执行：
db.adminCommand({ setParameter: 1, operationTimeout: 300000 })（单位毫秒，这里设5分钟） - 验证：
db.adminCommand({ getParameter: 1, operationTimeout: 1 })，返回值必须匹配 - 注意：该设置全局生效，会影响所有长耗时命令（如大聚合、建索引），别盲目设成几小时
客户端仍需配好socketTimeout和流式上传
虽然它不解决根本超时，但能避免上传中途因网络抖动断连：
- Java Driver 5.x+默认
socketTimeout仅60秒，大文件必中断，务必显式设置：SocketTimeoutSettings.builder().readTimeout(300, TimeUnit.SECONDS) - Node.js必须用
fs.createReadStream()直连uploadStream，禁用bodyParser，避免Buffer.from()把整文件拉进内存 - PHP中
uploadFromStream()的$source必须是真实可读流（如fopen('php://temp', 'w+b')），别用file_get_contents()+php://memory - chunkSizeBytes建议设为1–4MB（
uploadOptions.chunkSizeBytes），太小增加请求次数，太大拖慢单次写入
真正容易被忽略的是：operationTimeout改完后，得同步检查上传路径是否全程流式——哪怕服务端宽限5分钟，上游用readFileSync把2GB文件塞进内存，Node进程照样OOM，根本到不了GridFS层。
