GridFS 默认启用 MD5 计算会拖慢写入且集群 CPU 突增；MongoDB 4.4 及之前版本中，PyMongo 等驱动在上传时自动计算并存储 MD5，高并发小文件场景下造成冗余 CPU 消耗；从 5.0 起 md5 字段已弃用，但驱动默认仍计算；PyMongo 3.12+ 需在 GridFSBucket 初始化时传 disable_md5=True 才生效，上传时传参数无效。
GridFS 默认启用 MD5 计算会拖慢写入且集群里 CPU 突增
MongoDB 4.4 及之前版本中，GridFSBucket 在上传文件时默认调用 md5 计算并存入 files 集合的 md5 字段。这个计算在客户端做，单机影响不大；但集群中高并发上传小文件（比如日志切片、缩略图）时，大量 Node.js 进程或 Python 解释器反复跑哈希，CPU 直接顶满，而实际业务根本不用校验 MD5。
- 不是服务端行为，是驱动层（如
pymongo、mongodb-node-driver）在uploadFromStream或openUploadStream内部自动触发的 - 从 MongoDB 5.0 开始，
md5字段已标记为 deprecated，但驱动默认逻辑没变，仍会算 - 如果你从没读过
md5字段、也没配任何校验逻辑，这个计算纯属冗余
Python（PyMongo）关闭 GridFS MD5 的唯一有效方式
别信文档里“设置 disable_md5=True”这种模糊说法——PyMongo 3.12+ 才支持，而且必须传进 GridFSBucket 构造函数，不是上传时临时加参数。
- 错误写法：
bucket.upload_from_stream(..., options={'disable_md5': True})→ 无效，驱动直接忽略 - 正确写法：
bucket = GridFSBucket(db, disable_md5=True)→ 必须初始化桶时指定 - 注意：这个开关只影响新上传，不影响已有文件的
md5字段（也不会删它） - 如果用的是旧版 PyMongo（_hash_gridfs_chunk，不推荐
Node.js（mongodb driver）跳过 MD5 的两种场景处理
官方驱动直到 4.13+ 才通过 disableMD5 选项暴露控制权，老版本（如 3.x、4.0–4.12）压根没这开关，只能绕开。
- 4.13+：创建桶时传
{ disableMD5: true }，例如new GridFSBucket(db, { disableMD5: true }) - 4.12 及更早：无法关，但可改用
db.collection('fs.chunks').insertOne()+db.collection('fs.files').insertOne()手动写两表，跳过所有驱动封装逻辑 - 手动写要注意：必须自己生成
_id（建议用ObjectId()）、填对files_id和n字段，否则find会失败 - 手动写没有自动分块逻辑，chunk 大小需严格按
chunkSizeBytes（默认 255KB）切，否则downloadToStream解析错位
为什么不开 MD5 一般没问题，但某些场景要小心
关掉 MD5 不等于放弃完整性校验，只是放弃那个低效、单点、且 MongoDB 官方已弃用的字段。真需要校验，有更靠谱的替代路径。
- CDN 回源或跨机房同步时，靠
etag（即md5）做缓存比对？→ 改用sha256存到自定义字段，上传时客户端算好塞进metadata - 运维要求每份文件可追溯哈希？→ 用
mongosh脚本批量重算并更新metadata.sha256，不走上传链路 - 担心传输中损坏？→ TCP 层和 WiredTiger 日志已覆盖大部分场景；极端要求可用客户端
zlib.crc32做轻量校验，比 MD5 快 3–5 倍 - 别忘了：GridFS 本身不提供端到端一致性保证，
files和chunks是两个集合，异常中断可能导致孤儿 chunk —— 这比少个 MD5 严重得多
真正卡 CPU 的从来不是 MongoDB 服务端，而是你没意识到驱动在替你默默干重活。关开关很简单，难的是确认下游有没有人偷偷依赖那个 md5 字段做判断。
