开篇问题上一篇我们拆了对象存储与文件安全。对象存储里有一个很典型的设计：文件本体放在 S3； 临时文件过期时间放在 MongoDB； 真正删除动作交给 BullMQ； 队列本身又依赖 Redis。这已经把 FastGPT 的基础设施分工暴露出来了。在 FastGPT 里，MongoDB、Redis 和 BullMQ 不是并列替代关系。它们分别解决不同问题：MongoDB：保存长期业务状态； Redis：保存短期状态、缓存、锁和流式镜像； BullMQ：保存待执行任务与 worker 调度状态。如果边界混乱，会出现很多工程问题：把长期业务状态只放 Redis，重启或过期后状态丢失； 把高频短期计数全写 MongoDB，数据库压力变大； 把可查询的训练状态只放 BullMQ，业务页面很难展示准确进度； 把删除外部资源放在 API 同步路径里，用户请求被慢操作拖住； 把队列投递视为强一致，进程崩溃时会漏任务。所以第 31 篇我们专门看：FastGPT 如何划分 MongoDB、Redis 和 BullMQ 的使用边界？