gridfs本身不支持热冷分离，需通过应用层控制实现：为热文件和冷文件分别创建独立bucket并指向不同mongodb部署，手动迁移文件并确保读请求按业务逻辑路由到对应bucket。
GridFS 本身不支持热冷分离，必须靠外部策略驱动
GridFS 是文件分块存储协议，不是数据生命周期管理工具。它把一个文件拆成 chunks 和 files 两个集合存，但所有块默认写到同一数据库、同一副本集或分片集群里，没有内置的“冷存档路径”或“按时间自动迁移”能力。想实现热冷分离，得在应用层控制文件写入目标、迁移时机和读取路由。
用不同 GridFS bucket 实现物理隔离
最直接可控的方式是为热文件和冷文件分别创建独立的 GridFS bucket，底层指向不同 MongoDB 部署：
- 热 bucket（如
fs_hot）连接高性能副本集（SSD + 高内存） - 冷 bucket（如
fs_cold）连接低成本归档集群（HDD 或只读副本集），甚至挂接对象存储网关（如 MinIO + MongoDB 模拟层） - bucket 名称必须显式指定，不能复用默认
fs：驱动中初始化时传BucketOptions.SetName("fs_cold") - 注意：两个 bucket 的
files和chunks集合名会带前缀（如fs_cold.files），互不干扰，也无需跨 bucket 查询
冷文件迁移不能靠 GridFS 自动触发，得手动搬运
已有文件不会因为“变冷”就自己从 fs_hot 搬到 fs_cold。迁移需三步闭环操作：
- 先查出待归档文件：用
find({ "uploadDate": { $lt: ISODate("2024-01-01T00:00:00Z") } })扫描fs_hot.files - 逐个下载再上传：调用
downloadToStream()→ 保存临时文件或流式转发 → 调用冷 bucket 的uploadFromStream() - 确认无误后删除原文件：用
delete()删除fs_hot中对应_id，否则元数据与块残留，浪费空间 - 关键点：迁移过程要幂等，建议加
filename+uploadDate复合唯一索引防止重复上传；删除前务必验证冷端文件 MD5 或大小一致
读请求如何定向到冷 bucket？靠应用逻辑而非 readPreferenceTags
readPreferenceTags 只对普通集合查询生效，GridFS 的 find/openDownloadStream 不走标准查询路由，而是直连 bucket 对应的数据库连接。所以冷热读分离只能靠业务代码判断：
- 根据文件创建时间或业务标签（如
type: "archive"）决定用哪个 bucket 实例 - 示例逻辑：
if (file.uploadDate - 不要试图给 GridFS 集合加 tags 并配
readPreferenceTags——无效，驱动根本不解析这个参数 - 如果冷 bucket 后端是只读副本集，记得在连接字符串里设
readPreference=secondary，避免全打到主节点
真正麻烦的不是搬文件，而是迁移窗口期的数据一致性：上传冷 bucket 和删除热 bucket 之间若有并发写（比如用户重传同名文件），容易丢失或重复。必须加分布式锁或版本号校验，这点常被跳过。
