FastAPI中依赖注入与字段验证的执行顺序问题分析

问题现象

在FastAPI应用中，当同时使用Pydantic模型进行请求体验证和依赖注入时，开发者可能会遇到一个看似反常的现象：即使请求体字段验证失败，依赖注入函数仍然会被执行。具体表现为，当某个必填字段(如示例中的nurse_master)未提供时，虽然最终会抛出RequestValidationError，但数据库连接依然被创建，甚至进入了依赖注入函数的yield阶段。

技术背景

FastAPI框架在处理请求时，会按照以下顺序执行：

1. 路由参数解析和验证
2. 请求体解析和验证
3. 依赖注入解析
4. 路由函数执行

在正常情况下，字段验证应该在依赖注入之前完成。然而，在某些情况下，特别是当依赖注入函数使用生成器(yield)方式实现时，可能会出现验证错误与依赖注入执行顺序的交叉问题。

问题根源

出现这种现象的根本原因在于Python生成器的执行机制。当依赖注入函数使用yield实现时：

1. FastAPI会先执行到yield语句之前的所有代码
2. 然后才会进行后续的参数验证
3. 如果验证失败，会通过生成器的throw方法将异常抛回到yield点

这就解释了为什么在示例中，即使nurse_master字段验证失败，数据库连接依然被创建，并且错误日志显示异常是在yield db处被捕获的。

解决方案

方案一：调整依赖注入实现方式

将数据库会话管理改为上下文管理器模式，可以更清晰地控制资源生命周期：

from contextlib import asynccontextmanager

@asynccontextmanager
async def get_db():
    db = SessionLocal2()
    try:
        yield db
    except Exception as e:
        logger.exception(e)
        db.rollback()
        raise
    finally:
        db.close()

方案二：分离验证与数据库操作

确保所有验证逻辑在依赖注入之前完成：

async def create_nurse(
    item: NurseNewSchema,  # 先验证
    db: Session = Depends(get_db)  # 后获取数据库连接
):
    # 业务逻辑

方案三：优化错误处理

在依赖注入中添加对验证错误的特殊处理：

def get_db():
    db = SessionLocal2()
    try:
        yield db
    except RequestValidationError:
        db.close()
        raise
    except Exception as e:
        logger.exception(e)
        db.rollback()
        raise
    finally:
        if not db.in_transaction():
            db.close()

最佳实践建议

1. 对于数据库连接等昂贵资源，建议使用上下文管理器模式管理生命周期
2. 在依赖注入函数中，明确区分验证错误和业务错误的不同处理方式
3. 考虑使用中间件或在应用层面统一处理数据库会话，而不是在每个路由中单独处理
4. 对于复杂的验证逻辑，可以使用FastAPI的依赖注入系统将其拆分为多个层次

性能考量

虽然这个问题看起来是执行顺序的问题，但在高并发场景下，不必要的数据库连接创建可能会影响性能。使用连接池(如SQLAlchemy的Engine)可以缓解这个问题，因为连接池会复用已有连接而不是每次都创建新连接。

总结

FastAPI的依赖注入系统虽然强大，但在与Pydantic验证和生成器模式结合使用时，需要注意执行顺序和资源管理问题。通过理解框架的内部工作机制，开发者可以更好地控制应用的行为，编写出既健壮又高效的代码。特别是在处理数据库连接等资源时，合理的生命周期管理不仅能避免资源泄漏，还能提高应用的响应速度和稳定性。