mongodump+mongorestore不能直接迁移GridFS，必须显式导出fs.files和fs.chunks集合并严格保证关联性、顺序及索引，否则文件损坏或读取失败。
直接迁移 GridFS 文件到新集群，不能只靠 mongodump + mongorestore —— 它们默认不处理 .files 和 .chunks 集合的关联性，容易丢 chunk 或元数据错位，导致文件损坏或读取失败。
最稳妥的方式取决于迁移范围：同库跨桶、同集群跨库、跨集群。三类场景对应三种做法，选错就可能要重跑。
同数据库内 GridFS 桶间迁移（如 bucket1 → bucket2）
这是唯一能绕过 GridFS API、直接操作底层集合的场景，性能高且原子性强。
- 必须显式访问
bucket1.files和bucket1.chunks两个集合，不能用GridFSBucket实例的find()或openDownloadStream()—— 它们不暴露 chunk 关联逻辑 - 迁移顺序不能颠倒：先插入
bucket2.files，再按相同_id批量查bucket1.chunks并插入bucket2.chunks；否则bucket2.chunks中的files_id会指向不存在的文档 - 注意
chunk文档里的n字段必须保持原序，否则重建文件时顺序错乱；mongorestore不保证插入顺序，所以必须用insertMany()并确保 list 顺序与源一致 - Java 示例中若用
into(new ArrayList())获取 chunk 列表，需确认驱动版本支持有序返回（4.11+ 默认保序，4.7–4.10 需加.sort("n", 1)）
跨数据库但同 MongoDB 集群迁移（如 db1.bucket → db2.bucket）
不能复用同库迁移逻辑，因为 db.getCollection("db1.bucket.files") 这种写法在驱动里不合法 —— 集合名不含数据库前缀。
- 必须分别获取两个数据库实例：
MongoDatabase db1 = client.getDatabase("db1");、MongoDatabase db2 = client.getDatabase("db2"); - 再通过
db1.getCollection("bucket.files")和db2.getCollection("bucket.files")获取对应集合，注意集合名是纯字符串，不带数据库名 - 权限要同时覆盖两个库：用户需对
db1有read，对db2有readWrite；仅root角色不一定生效，建议显式赋权：db.grantRolesToUser("migrator", [{role:"read", db:"db1"}, {role:"readWrite", db:"db2"}]) - chunk 插入前建议校验目标
bucket.chunks是否为空，避免重复 ID 冲突；in("_id", ...)查询在跨库时仍有效，但files_id字段值必须与目标bucket.files中的_id类型完全一致（比如都是ObjectId，不能混用字符串）
跨 MongoDB 集群迁移（含 Atlas、自建、不同版本）
这时底层集合直连失效，必须回归工具链，但 mongodump/mongorestore 有隐藏陷阱。
-
mongodump --db mydb --collection mybucket.files只导出元数据，mybucket.chunks必须**显式单独 dump**，漏掉就只剩空壳文件 -
mongorestore不自动重建 GridFS 关系：它把.files和.chunks当普通集合导入，不会触发 GridFS 的校验逻辑；必须确保导入后.chunks中的files_id字段与.files中的_id严格匹配（类型、值、大小写） - 如果源集群是 MongoDB 6.0+，目标为 Atlas，优先用 Atlas 控制台的「实时迁移（拉取）」功能 —— 它内部会识别 GridFS 模式并做 chunk 关联校验，比手动 dump/restore 少踩 80% 的坑
- 若必须用命令行，加
--drop参数清空目标 bucket 再 restore，否则已有文件 ID 冲突会导致部分 chunk 被跳过（mongorestore默认不覆盖）
真正容易被忽略的是 chunk 的 data 字段二进制完整性。无论用哪种方式，迁移后务必抽样验证：用 GridFSBucket 从新位置打开文件，调用 downloadToStream() 并比对原始 MD5 —— 光看文档数量一致没用，chunk 损坏或顺序错位时，文件可能打不开或内容截断。
