GridFS到S3迁移必须采用“下载→上传”两步流，不能用mongodump/mongoexport；需按files.chunks关系重建文件，校验ContentLength，并同步元数据至独立索引库以支持查询。
GridFS 到 S3 迁移不能靠 mongodump/mongoexport
因为 mongodump 和 mongoexport 只能导出 files 和 chunks 集合的原始 BSON/JSON，但 S3 不认这些结构——它只存完整二进制对象。你导出的 chunks 文档是碎片化的 Base64 或 BinData 字段，没法直接拼成文件。强行解析再组装，极易出错（比如 chunk 编号错位、丢失最后一个不完整块），且性能极差。
必须走“下载 → 上传”两步流，且要按 files.chunks 关系重建文件
GridFS 文件不是单个文档，而是由 files 集合中一条元数据 + chunks 集合中多条块文档共同构成。迁移时必须：
- 先查
files集合获取目标文件的_id、filename、length、chunkSizeBytes - 再用该
_id查询chunks集合，按n字段升序排序（顺序错就损坏文件） - 把所有
data字段（BinData类型）拼接成完整字节流 - 用 AWS SDK 的
putObject写入 S3，设置ContentType（从files的contentType字段取）和ContentDisposition（建议设attachment; filename="xxx"）
Java 实现的关键陷阱：不要用 GridFSBucket.downloadToStream() 做批量迁移
GridFSBucket.downloadToStream() 看似方便，但它内部会反复查询 chunks 并做内存缓冲，**在大批量迁移时极易 OOM**（尤其视频类大文件）。更稳的方式是绕过高层 API，直接操作底层集合：
- 用
collection.find()批量拉files文档（加$limit分页防内存爆） - 对每个文件 ID，执行
chunksColl.find(eq("files_id", fileId)).sort(ascending("n")) - 用
ByteBuffer或ByteArrayOutputStream拼接chunk.data，边读边写 S3（避免全加载进内存） - 务必校验最终写入 S3 的
ContentLength是否等于files.length，不等则失败重试
S3 存储路径设计要兼容 GridFS 元数据检索能力
迁完后，原应用如果还依赖 GridFS 的条件查询（如按 uploadDate、metadata.tags 查文件），S3 本身不支持这类查询。常见补救方案：
- 把
files集合的必要字段（_id、filename、uploadDate、metadata）单独同步到一个 MongoDB 集合（如s3_file_index），S3 key 设为{_id.toHexString()}/{filename} - 或用 DynamoDB 存索引，S3 key 加前缀如
gridfs-migrated/{_id}/original.jpg - 切记：S3 的 LIST 操作成本高、延迟大，**绝不能靠
listObjectsV2回扫全桶来模拟 find()**
真正麻烦的不是下载或上传，而是迁移期间新文件还在写入 GridFS —— 你需要停写窗口，或加双写逻辑，否则漏掉增量文件就无法回溯。
