GridFS写入时真正加锁的是fs.files和fs.chunks集合，其中fs.files的insertOne操作形成并发瓶颈；高吞吐需预分配文件ID并用openUploadStreamWithId跳过元数据竞争。
GridFS 写入时到底锁了什么？
GridFS 本身不加锁，真正锁的是底层的 fs.files 和 fs.chunks 这两个集合。MongoDB 4.0+ 默认使用集合级意向锁（intent locks），写入一个大文件时，insertOne 到 fs.files 会持有一个集合级排他意向锁（IX → X），同时每个 fs.chunks 分片插入也会在该集合上申请 IX 锁。多个并发写入不会阻塞彼此的 chunks 插入（因为 IX 是兼容的），但 fs.files 的首次插入可能成为瓶颈——尤其当大量文件几乎同时开始上传、争抢写入元数据时。
为什么并发写入吞吐卡在 20–30 QPS？
这不是 GridFS 的“设计缺陷”，而是默认行为下隐含的串行点：所有写操作都通过同一个 GridFSBucket 实例调用 openUploadStream，而该方法内部会同步执行 fs.files.insertOne()。若未显式指定 bucketName 或复用同一 bucket 实例，多个线程/协程会排队等待元数据写入完成。常见表现是监控看到 fs.files 集合写入延迟突增，fs.chunks 却很空闲。
- 避免复用单个
GridFSBucket实例做高并发上传；按业务逻辑分桶（如"uploads_2024q3"）可天然隔离锁竞争 - 不要在上传前手动
insertOne到fs.files—— 这会绕过 GridFS 的 chunk 分片逻辑，导致后续读取失败 - 确认 MongoDB 版本 ≥ 4.2：4.0 虽支持意向锁，但 4.2 起对
fs.chunks的批量插入做了 write concern 优化，降低锁持有时间
chunkSizeBytes 设多大才不影响并发？
chunkSizeBytes 不影响锁粒度，只影响单次 fs.chunks 插入的数据量和频次。设得太小（如 16KB）会导致每 MB 文件产生 64 次插入请求，网络往返和日志刷盘开销上升；太大（如 4MB）则单次写入耗时变长，可能拖慢单个上传流的响应。实测在千兆内网 + WiredTiger 引擎下，256KB 是吞吐与延迟较优的平衡点。
注意：chunkSizeBytes 是创建 GridFSBucket 时的固定参数，不能 per-upload 覆盖。若需混合大小文件，建议按场景拆 bucket，例如：
const largeBucket = new GridFSBucket(db, { bucketName: 'large_files', chunkSizeBytes: 1024 * 1024 });
const smallBucket = new GridFSBucket(db, { bucketName: 'small_assets', chunkSizeBytes: 32 * 1024 });真正提升吞吐的关键不是调参，而是绕开元数据写入竞争
最有效的做法是预分配文件 ID 并跳过 fs.files 的自动插入。用 ObjectId() 生成唯一 _id，先手动插入最小元数据（至少含 _id, length, chunkSize, uploadDate），再用 openUploadStreamWithId 直接写 chunks。这样所有上传流完全并行，fs.files 只是一次性轻量写入，不再成为瓶颈。
容易被忽略的一点：预插入的 length 字段必须准确，否则 openUploadStreamWithId 后续写入超出该长度的 chunk 会被静默截断——MongoDB 不校验，客户端也无报错。
