FastAPI单引擎下同时使用SQLAlchemy普通Session和scoped_session是否合规

你当前同时使用两类Session的方案是完全合理的，不存在不推荐的问题，也不需要强制更换其他方案，原因如下：

• 两类Session本质都基于同一个引擎的连接池创建，不存在资源冲突。普通Session配合FastAPI的Depends是官方推荐的请求链路会话管理方案，请求结束调用close()会正常归还连接到连接池；后台多线程场景使用scoped_session是SQLAlchemy官方适配多线程场景的标准方案，每个线程持有独立会话，执行结束调用remove()也会正常释放连接，只要你按规范处理生命周期，就不会出现之前的连接池占满问题。
• 两类Session的使用场景完全匹配各自的运行逻辑：请求链路的Session生命周期和HTTP请求绑定，用普通Session足够简洁；后台线程的生命周期和请求无关，用scoped_session能保证线程隔离，避免会话跨线程调用的安全问题。

如果你希望统一会话管理逻辑，也可以调整为全链路使用scoped_session，不需要拆分两类实现：

• 请求链路的Depends直接返回scoped_session实例，在依赖的yield结束后调用remove()即可，效果和当前用普通Session完全一致，还能统一会话的创建、释放逻辑。
• 如果后台任务是用FastAPI自带的BackgroundTasks实现，注意不要直接传递请求链路的Session给后台任务：请求结束后Session会被提前关闭，会导致后台任务执行报错，这种场景依然推荐单独给后台任务创建独立的scoped_session实例。

如果后续业务并发量持续上涨，可以根据服务器的数据库连接上限调整引擎的连接池参数，适当调大pool_size（连接池常驻连接数）和max_overflow（最大溢出连接数），避免高并发场景下连接不够用的问题。

内容的提问来源于stack exchange，提问作者Joseph Asaf Gardin