是，mongodump + mongorestore 无法直接迁移 GridFS，因默认不识别 fs.files/fs.chunks 的逻辑关联，需显式指定集合并手动建索引；mongosync/副本集切换不适用；mongofiles 仅适合小规模简单场景；Python 脚本最可控但须保证 files_id、chunk.n 一致及 md5 验证。
用 mongodump + mongorestore 无法直接迁移 GridFS？
因为 mongodump 默认只导出普通集合，fs.files 和 fs.chunks 这两个 GridFS 元数据/数据集合不会被自动识别为“GridFS 实体”——它只是把它们当普通集合导出，但 mongorestore 不会重建文件逻辑关系，导致恢复后 GridFSBucket 找不到文件或读取出错。
- 必须显式指定
fs.files和fs.chunks集合名（默认前缀是fs，但可自定义，迁移前先确认：db.getCollectionNames().filter(n => n.includes('.files') || n.includes('.chunks'))） - 导出时加
--collections参数，例如：mongodump --host old-cluster:27017 --db myapp --collections fs.files,fs.chunks -o ./gridfs-dump - 导入时不能依赖自动重建索引，需手动在目标库运行：
db.fs.files.createIndex({"filename": 1, "uploadDate": 1})和db.fs.chunks.createIndex({"files_id": 1, "n": 1})
为什么不能用 mongosync 或副本集切换？
mongosync（现为 mongodb-migrate）不支持 GridFS 元数据一致性校验；而跨集群意味着没有共享复制流，副本集切换只适用于同集群内节点替换，不是迁移方案。
- GridFS 本质是两集合协同+客户端驱动的抽象，同步工具只看单文档操作，无法保证
files插入和对应chunks分片写入的事务边界 - 若源库持续写入，单纯靠一次 dump/restore 会丢数据；需停写或结合
changeStream捕获增量——但注意：GridFS 操作不直接产生 changeStream 事件，要监听fs.files和fs.chunks的变更并做关联还原 - 生产环境建议用应用层双写过渡：新文件同时写入新旧 GridFS，老文件按需迁移，再逐步切流量
mongofiles 命令行工具适合小规模迁移吗？
适合，但仅限于文件名明确、无嵌套路径、且总量在几千以内的情况。它本质是逐个 put/get，网络开销大、无并发控制、不处理元数据字段（如 metadata 对象）。
- 导出所有文件：
mongofiles --host old-cluster:27017 --db myapp list > files.txt，再循环get到本地 - 导入时默认用
fs前缀，若源库用了自定义前缀（如media.files），mongofiles无法指定，会失败 - 文件名含特殊字符（如
/、空格）时，mongofiles解析易出错，报错类似：error: file not found: /path/to/file—— 实际是命令行分词问题，得加引号或改用驱动脚本
用 Python 驱动写脚本迁移最可控，但要注意什么？
核心是保持 files_id 和 chunk.n 顺序一致，避免 chunk 错位导致文件损坏。PyMongo 的 GridFSBucket 不允许直接插入 raw chunk 文档，必须走 upload_from_stream 流式写入。
- 不要用
insert_one直接写fs.chunks，否则download_to_stream会因缺失校验字段（如length,uploadDate）失败 - 迁移时优先读
fs.files，对每个文件调用bucket.open_download_stream(file_id)再upload_from_stream到目标 bucket，这样能继承原始metadata和contentType - 大文件（>100MB）要设好
socketTimeoutMS和重试逻辑，否则容易中断；chunkSizeBytes 参数两端必须一致，否则目标端解码错乱
md5 是否和源端完全一致——fs.files.md5 字段只在旧版驱动中默认写入，新版默认关了，得自己算。别跳过这步。 
