FastAPI中用with替代Depends管理数据库会话是否为最佳实践？有无替代方案？

问题背景 #

在使用FastAPI时遇到数据库数据读取及“丢失”问题，于是尝试用with语句替代Depends来管理数据库会话，代码示例如下：

新实现（with语句） #

with SessionManager() as db:

    @router.get("/{id}", response_model=...)
    async def get_by_id(id: UUID) -> JSONResponse:
        result = crud_xxx.get_by_id(db, id)

    @router.get("/{text}", response_model=...)
    async def get_by_text(text: str) -> JSONResponse:
        result = crud_xxx.get_by_text(db, text)

原实现（Depends） #

@router.get("/{id}", response_model=...)
async def get_by_id(id: UUID, db: SessionLocal = Depends(deps.get_db)) -> JSONResponse:
    result = crud_xxx.get_by_id(db, id)

用with替代Depends是否为良好实践？ #

这种做法不仅不是良好实践，反而存在严重的设计错误：

• 当前的with代码块是在路由定义阶段执行的，而非每次请求处理时。这意味着所有请求会共享同一个数据库会话实例，会引发一系列并发问题：会话状态混乱、数据竞争、连接泄漏，甚至导致事务逻辑完全错误。
• FastAPI的请求生命周期要求每个请求拥有独立的数据库会话，而你的写法直接违背了这个原则，会让应用在多请求场景下出现不可预测的问题。

其他可行方案 #

1. 修复Depends的标准用法（最推荐） #

先排查原deps.get_db的实现是否符合请求级会话的要求，正确的依赖项应该为每个请求创建新会话，并在请求结束后自动关闭：

# 正确的get_db依赖实现
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

如果之前出现数据“丢失”问题，大概率是CRUD操作中的事务处理不当：比如写操作后未执行db.commit()，或者读取时的事务隔离级别导致看不到未提交的数据，需要检查业务代码中的事务逻辑。

2. 在依赖项内部结合with上下文管理器 #

如果习惯用with来管理会话生命周期，可以把with放在依赖项内部，保证每个请求创建新会话：

def get_db():
    with SessionManager() as db:
        yield db

然后路由依然使用Depends(get_db)，这样每个请求都会进入独立的with块，会话在请求结束后自动关闭，既符合上下文管理器的习惯，又遵循请求级会话的原则。

3. 使用中间件全局管理会话 #

通过FastAPI中间件在请求开始时创建会话，请求结束时关闭，会话存储在请求状态中供路由使用：

@app.middleware("http")
async def db_session_middleware(request: Request, call_next):
    request.state.db = SessionLocal()
    try:
        response = await call_next(request)
    finally:
        request.state.db.close()

路由中通过request.state.db获取会话：

@router.get("/{id}", response_model=...)
async def get_by_id(id: UUID, request: Request) -> JSONResponse:
    result = crud_xxx.get_by_id(request.state.db, id)

这种方式适合全局统一管理会话，但如果使用异步ORM，需要注意异步上下文的适配。

内容的提问来源于stack exchange，提问作者James