gridfs 不支持直接归档到 s3 等对象存储，必须在应用层手动实现“下载→上传→删除”三步闭环，确保幂等、可重试，并加分布式锁避免并发冲突。
GridFS 本身不支持直接归档到云端对象存储（如 S3、MinIO、OSS），MongoDB 7.0 也未内置该能力。你必须在应用层实现“读出 → 转存 → 清理”闭环，且不能依赖 GridFS 自动迁移或触发器。
为什么不能用 mongofiles 或 GridFSBucket 直接对接 S3
因为 mongofiles 是纯客户端工具，只与 MongoDB 通信；GridFSBucket 的 uploadFromStream() 和 downloadToStream() 也只面向本地流或数据库内部集合。S3 等对象存储需要独立 SDK（如 boto3、aws-sdk-go）和 HTTP 签名逻辑，MongoDB 驱动不封装这部分。
- 试图给
GridFSBucket配置 S3 endpoint 或自定义 write concern —— 无效，驱动会报connection refused或解析失败 - 把 S3 URL 存进
metadata.url字段不是归档，只是元数据标记，文件本体仍在 MongoDB 中 - 用
$merge聚合写入远程 S3？不行，$merge只支持同集群内其他集合，不支持外部存储
归档流程必须手动分三步走：下载 → 上传 → 删除
核心是确保每一步可验证、可重试、幂等。尤其注意 chunk 读取顺序和流式转发，避免内存爆满。
- 从热 bucket 下载：用
bucket.openDownloadStream(fileId)获取流，不要调downloadToStream()到临时文件（浪费磁盘 I/O） - 直传对象存储：用 SDK 的
PutObject（S3）或PutObjectwith streaming（MinIO），传入原始流 + 显式设置ContentMD5和ContentType - 删除前校验：先查 S3 对象的
ETag（即 MD5 hex）是否与fs.files.md5一致；再比对ContentLength是否等于fs.files.length - 删除操作必须用
bucket.delete(fileId)，而非删fs.files文档——否则fs.chunks块残留，造成空间泄漏
如何让冷文件读请求自动路由到 S3 而非 MongoDB
没有中间件或代理时，只能靠业务代码判断。别碰 readPreferenceTags，它对 GridFS 无效。
- 读逻辑需检查
files.metadata.archiveStatus === "moved-to-s3"，再构造 S3 presigned URL 或调 SDKGetObject - 若使用 nginx-gridfs，它只代理 GridFS 请求，无法跳转 S3；必须改用反向代理（如 Nginx + Lua）做条件重写
- 连接 S3 时务必设 timeout（建议 ≤ 15s），避免一个慢请求拖垮整个文件服务线程池
- 冷路径要加缓存头：
Cache-Control: public, max-age=31536000，但注意 S3 默认不返回ETag作为强校验，需开启ChecksumAlgorithm: SHA256才可靠
真正容易被忽略的是迁移过程中的并发读写冲突：如果归档期间用户正在下载该文件，openDownloadStream() 可能读到部分已删块；而删除操作又不可回滚。所以生产环境必须加分布式锁（如 Redis lock），并限定归档窗口为低峰期。
