FastAPI中Depends效率相关：为何用依赖注入而非全局字典传递对象？

1. 为什么不直接用全局字典存储初始化对象 #

• 全局状态不可控：测试阶段需要Mock依赖时，全局字典需要手动修改、用完还要复原，多协程/多线程环境下极易出现数据串扰。尤其是请求级别的状态（比如当前登录用户、和请求绑定的数据库会话）无法用全局字典存储，总不能为了避免冲突每次请求都给全局字典加锁。
• 生命周期绑定不灵活：全局对象默认和应用生命周期绑定，但大量依赖的生命周期和请求绑定（比如数据库连接、权限校验实例），请求结束就要释放资源，塞全局字典里需要自己手动写逻辑处理创建、销毁流程，极易出现资源泄漏。
• 依赖关系不透明：路由函数直接从全局字典取对象时，其他维护者读代码根本不知道接口依赖了哪些组件，需要翻全局字典的赋值逻辑才能理清，维护成本极高。而Depends写在路由参数里，一眼就能看出接口的依赖项，还能和FastAPI自动生成的OpenAPI文档联动，比如依赖包含OAuth2校验时，文档会自动生成鉴权操作入口，全局字典无法实现这类能力。

2. 为什么不直接写工具函数常规调用 #

Depends本身支持传入普通工具函数，但它比直接调用有几个不可替代的优势：

• 同请求自动缓存：同一个请求内多次调用同一个依赖，Depends只会执行一次，返回缓存的结果。比如你写了get_current_user依赖，接口逻辑、权限校验、操作日志三个环节都要用到，直接调函数会触发三次数据库查询，用Depends一次请求只会查询一次。
• 自动参数解析校验：如果依赖的参数来自请求（比如Query、Header、Path参数），FastAPI会自动注入对应值，同时完成类型校验，格式不符合直接返回422错误，不需要你手动在工具函数里拿request对象取参数、手写校验逻辑。
• 自动处理嵌套依赖：你可以在依赖里再嵌套其他Depends，比如get_current_user依赖get_oauth2_token，get_oauth2_token又依赖get_db_session，Depends会自动处理依赖树的初始化顺序，自己写工具函数的话需要手动一层层传参数，代码冗余度会非常高。

3. 关于FastAPI DI和Spring DI的差异误解 #

「FastAPI的DI本质是调用可调用对象」的判断是准确的，但这是设计取舍而非缺陷：

• FastAPI的DI天生支持多生命周期依赖：你可以通过lifespan事件初始化应用级别的单例依赖，然后在Depends里直接返回该单例，效果和Spring的Singleton Bean完全一致；也可以编写请求级别的依赖，每次请求新建实例，对应Spring的Request Scope Bean；不需要手动维护全局字典的作用域逻辑。
• 不存在「仅适用于无状态类/可调用对象」的限制：你完全可以在依赖里返回有状态的对象，比如每个请求绑定的数据库会话、携带当前用户信息的业务逻辑类实例，还可以通过生成器语法自动处理状态销毁，示例如下：

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

上述代码返回的db就是有状态的数据库连接，Depends会自动处理创建和销毁流程，比手动维护全局连接池安全得多。

• 和Spring DI的核心差异是FastAPI的DI做了轻量无侵入的设计：不需要给类加额外注解、不需要扫描Bean，只要是可调用对象都能作为依赖使用，对Python这种动态语言来说，比Spring重容器的实现灵活很多。如果你偏好全局单例的实现方式，也可以把全局对象包在简单的依赖里返回，既保留了全局字典的使用习惯，还能享受到依赖透明、文档联动、测试方便的优势。

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