GridFS不支持随机写入，因其将文件分块存储且无seek+write接口，修改需整文件重传并手动清理旧chunk；真需随机写应更换存储方案。
GridFS 本身不支持随机写入
不能。GridFS 是 MongoDB 对大文件的分块存储方案，底层把文件切分成 255KB（默认）的 chunks 文档存进 fs.chunks 集合，元信息存在 fs.files。它没有提供类似 POSIX 文件系统的 seek + write 接口，所有“修改”本质是读出、改内存、再整份重写上传。
想改中间几个字节，实际得重传整个文件
常见错误现象：有人调用驱动里的 open_upload_stream 或 replace_one，以为能局部更新，结果发现旧文件被完整覆盖，或新 chunk 写进去但 length / md5 元数据没同步，导致后续 find 失败或校验报错。
- 必须先用
find_one拿到原始文件流，读全内容到内存或临时文件 - 在内存里用
bytes切片 + 拼接完成修改（比如data[1024:1028] = b'\x00\x01\x02\x03'） - 调用
bucket.upload_from_stream（PyMongo）或等价 API 重新上传——这会生成全新的一组chunks，旧 chunk 不会自动清理，需手动删 - 旧文件的
_id不再关联新数据，除非你显式调用delete并复用 ID，但驱动通常不鼓励这么做
替代方案：真需要随机写，别用 GridFS
使用场景很明确：频繁修改中间内容（如视频关键帧、数据库日志修补、二进制配置热更新）。GridFS 在这种场景下会放大 I/O 和存储开销，且并发写容易出错。
- 小文件（BinData 字段，用
$set更新指定字段，但依然无法只改字节，只能整个字段替换 - 大文件且需随机访问，更适合对象存储（如 S3）+ 数据库存 URL；S3 支持
PUT带Range头的部分更新（仅限追加或覆盖末尾），但标准 S3 也不支持真正意义上的中间字节覆盖 - 若必须本地随机写，考虑
mmap+ 普通文件系统，MongoDB 不该承担这个角色
性能与一致性风险常被低估
重传一个 1GB 文件，在网络不稳定或驱动超时设置不合理时，可能卡在 chunk 写一半，导致 fs.files 里 length 和实际 chunks 总大小不一致，后续 download_to_stream 会抛 FileNotFoundError 或返回截断数据。
- 务必检查驱动版本：PyMongo
4.7+对 GridFS 事务支持更稳，但事务不能跨 chunk 原子写，仍需应用层兜底 - 上传前算好
md5，上传后用bucket.open_download_stream回读校验，别只信返回的_id - 生产环境避免在单次请求里处理 >100MB 的 GridFS 修改，容易触发连接中断或 OOM
改字节这事，不是 MongoDB 不够快，是 GridFS 的设计压根没打算干这个活。真有需求，得从存储选型上换道，而不是在 upload_stream 里反复试错。
