GridFS写入在主节点切换时失败，是因为其uploadFromStream操作分块写入chunks和files集合，默认insertOne不可重试；若未启用retryWrites或配置不合规（如驱动版本低、连接串缺retryWrites=true、非副本集/分片集群），主从切换会导致NotPrimaryError或超时。
GridFS 本身不支持 Retryable Writes，但底层写操作可以启用——前提是集群拓扑、驱动版本、连接配置全部合规，否则会静默失效或报错。
为什么 GridFS 写入在主节点切换时失败
GridFS 的 uploadFromStream 实际是分块写入多个 chunks 集合文档 + 一条 files 文档。这些底层 insertOne 操作默认不可重试；一旦发生副本集主节点故障转移，正在写入的 chunk 可能因网络中断或写入确认丢失而卡住，最终触发超时或抛出 MongoNetworkError 或 NotPrimaryError。
这不是 GridFS 的 bug，而是驱动未开启重试机制 + 操作未落在可重试范围内导致的。
- 必须是副本集或分片集群（独立 mongod 不支持）
- 服务端
featureCompatibilityVersion≥ 3.6 - 客户端驱动版本需 ≥ Node.js 3.0 / Java 3.6 / Python 3.6
- 连接字符串中必须显式含
retryWrites=true（4.2+ 驱动虽默认开启，但部分环境仍需显式声明）
如何验证 retryWrites 是否真正生效
光加 retryWrites=true 不够——MongoDB 驱动只对特定写操作启用重试，且会跳过某些场景。最直接的验证方式是主动模拟主节点失联：
- 用
rs.stepDown()手动触发一次主从切换 - 在切换窗口内执行一次小文件上传（避免耗时干扰判断）
- 检查是否返回成功，而非
NotPrimaryError或长时间挂起 - 抓包或开启驱动日志（
loggerLevel: 'debug'）确认是否出现Retrying write due to...日志
若仍失败，大概率是：连接串没生效、驱动版本太低、或写操作被包装在事务/自定义 session 中覆盖了默认行为。
GridFS 上传必须搭配的三项关键配置
Retryable Writes 只解决“单次写失败后重试一次”的问题，但 GridFS 高并发下更常因流未释放、连接池卡死而失败。这三件事必须同步做：
- 连接池参数调优：
maxPoolSize=300、minPoolSize=30、maxConnectionIdleTimeMS=600000（10 分钟），防止连接堆积 - 上传流必须设超时并监听 error：
const uploadStream = bucket.openUploadStream(filename); uploadStream.setTimeout(30000); uploadStream.on('error', () => uploadStream.destroy()); - 禁用全局重试（
retryWrites=false）改由业务层控制：上传失败后调用bucket.delete()清理已写入的 chunk，再重试整个文件
容易被忽略的兼容性陷阱
Azure Cosmos DB for MongoDB 是常见盲区：它 4.2/6.0 兼容模式下支持 retryWrites，但 3.6 模式不支持；且无论哪个版本，GridFSBucket 的 openUploadStream 返回的流在 close 后不会自动 abort，必须手动调用 stream.destroy()，否则连接永不归还池中。
另一个隐性问题：如果上传逻辑嵌套在 withTransaction 里，整个 GridFS 操作将失去重试能力——事务内的写入不可单独重试，只能靠事务提交/回滚本身的重试保障，而 GridFS 分块写不在该保障范围内。
