不够，GridFS默认30秒服务端OperationTimeout易触发超时错误；需通过adminCommand动态调大operationTimeout、调整chunkSizeBytes至1～4MB、使用流式上传、上传前加uploadId以便失败后精准清理脏数据。
GridFS 上传超时默认是 30 秒，够用吗？
不够。尤其是上传几百 MB 甚至 GB 级文件时，30 秒极易触发 OperationTimeout 错误——不是代码写错了，而是 MongoDB 服务端主动中断了还在传输的请求。这个超时由服务端控制，默认值硬编码在 mongod 进程里，客户端驱动无法绕过，只能协同调整。
-
OperationTimeout 是服务端参数，和客户端的 socketTimeout、connectTimeout 完全不同，后者管连接建立和读写空闲，前者管整个操作生命周期
- 单纯加长客户端超时（比如设
timeout: 300000）没用：服务端 30 秒就 kill 掉了，客户端再等也是白等
- 常见报错类似：
Operation timed out after 30000 ms 或 command insert failed: operation exceeded time limit
怎么改服务端 OperationTimeout？
必须通过 adminCommand 动态修改，重启 mongod 不生效（它不是配置文件参数）。操作需有 clusterAdmin 权限：
- 登录
mongosh，执行：db.adminCommand({ setParameter: 1, operationTimeout: 300000 })
- 验证是否生效：
db.adminCommand({ getParameter: 1, operationTimeout: 1 })
- 注意：该设置是全局生效，影响所有 GridFS 操作（上传/下载/删除），也影响其他长耗时命令（如大聚合、索引构建）
光调超时还不够：分块大小和流式上传必须配好
超时只是表象，根本问题是单次写入压力过大。GridFS 默认 chunk 大小为 255KB，对超大文件来说，chunk 数量爆炸，元数据写入+索引更新开销陡增。应主动控制：
- 上传时显式指定
chunkSizeBytes，推荐 1MB～4MB（如 { chunkSizeBytes: 1048576 }），减少 chunk 文档数量，降低集合写入频次
- 必须用流式上传（
openUploadStream + pipe），禁用 uploadFromStream 全内存加载——否则 Node.js 进程可能 OOM
- 若网络极不稳定，考虑前端分片上传（如每片 10MB），后端按
n 字段写入对应 chunk，并在 fs.files 中标记 status: "uploading" 和已传 chunk 数，实现断点续传
上传中途失败后怎么清理“半截文件”？
GridFS 不会自动回滚。上传中断后，fs.files 里留着元数据文档，fs.chunks 里存着若干已写入的 chunk，形成脏数据，既占空间又干扰查询。
- 手动清理要两步走：先删
fs.chunks 中匹配 files_id 的所有 chunk，再删 fs.files 对应文档
- 更稳妥的做法是上传前生成唯一
uploadId（如 UUID），写入 metadata.uploadId，失败后用它批量清理：db.fs.chunks.deleteMany({ "files_id": { $in: db.fs.files.find({ "metadata.uploadId": "xxx" }, { _id: 1 }).toArray().map(x => x._id) } });<br>db.fs.files.deleteMany({ "metadata.uploadId": "xxx" });
- 别依赖
bucket.delete()：它只删完整文件，对中断上传无效
OperationTimeout 是服务端参数，和客户端的 socketTimeout、connectTimeout 完全不同，后者管连接建立和读写空闲，前者管整个操作生命周期timeout: 300000）没用：服务端 30 秒就 kill 掉了，客户端再等也是白等Operation timed out after 30000 ms 或 command insert failed: operation exceeded time limit
adminCommand 动态修改，重启 mongod 不生效（它不是配置文件参数）。操作需有 clusterAdmin 权限：
- 登录
mongosh，执行：db.adminCommand({ setParameter: 1, operationTimeout: 300000 }) - 验证是否生效：
db.adminCommand({ getParameter: 1, operationTimeout: 1 }) - 注意：该设置是全局生效，影响所有 GridFS 操作（上传/下载/删除），也影响其他长耗时命令（如大聚合、索引构建）
光调超时还不够：分块大小和流式上传必须配好
超时只是表象，根本问题是单次写入压力过大。GridFS 默认 chunk 大小为 255KB，对超大文件来说，chunk 数量爆炸，元数据写入+索引更新开销陡增。应主动控制：
- 上传时显式指定
chunkSizeBytes，推荐 1MB～4MB（如 { chunkSizeBytes: 1048576 }），减少 chunk 文档数量，降低集合写入频次
- 必须用流式上传（
openUploadStream + pipe），禁用 uploadFromStream 全内存加载——否则 Node.js 进程可能 OOM
- 若网络极不稳定，考虑前端分片上传（如每片 10MB），后端按
n 字段写入对应 chunk，并在 fs.files 中标记 status: "uploading" 和已传 chunk 数，实现断点续传
上传中途失败后怎么清理“半截文件”？
GridFS 不会自动回滚。上传中断后，fs.files 里留着元数据文档，fs.chunks 里存着若干已写入的 chunk，形成脏数据，既占空间又干扰查询。
- 手动清理要两步走：先删
fs.chunks 中匹配 files_id 的所有 chunk，再删 fs.files 对应文档
- 更稳妥的做法是上传前生成唯一
uploadId（如 UUID），写入 metadata.uploadId，失败后用它批量清理：db.fs.chunks.deleteMany({ "files_id": { $in: db.fs.files.find({ "metadata.uploadId": "xxx" }, { _id: 1 }).toArray().map(x => x._id) } });<br>db.fs.files.deleteMany({ "metadata.uploadId": "xxx" });
- 别依赖
bucket.delete()：它只删完整文件，对中断上传无效
chunkSizeBytes，推荐 1MB～4MB（如 { chunkSizeBytes: 1048576 }），减少 chunk 文档数量，降低集合写入频次openUploadStream + pipe），禁用 uploadFromStream 全内存加载——否则 Node.js 进程可能 OOMn 字段写入对应 chunk，并在 fs.files 中标记 status: "uploading" 和已传 chunk 数，实现断点续传fs.files 里留着元数据文档，fs.chunks 里存着若干已写入的 chunk，形成脏数据，既占空间又干扰查询。
- 手动清理要两步走：先删
fs.chunks中匹配files_id的所有 chunk，再删fs.files对应文档 - 更稳妥的做法是上传前生成唯一
uploadId（如 UUID），写入metadata.uploadId，失败后用它批量清理：db.fs.chunks.deleteMany({ "files_id": { $in: db.fs.files.find({ "metadata.uploadId": "xxx" }, { _id: 1 }).toArray().map(x => x._id) } });<br>db.fs.files.deleteMany({ "metadata.uploadId": "xxx" }); - 别依赖
bucket.delete()：它只删完整文件，对中断上传无效
超时不是孤立参数问题，它是服务端策略、客户端流控、网络容错、异常清理四层联动的结果。漏掉任何一层，都可能让“调大 timeout”变成掩耳盗铃。
