FastAPI中对象复用的最优方案：直接初始化vs依赖注入

全局初始化复用方案 #

优点 #

• 性能最优：客户端实例仅在应用启动时创建一次，所有请求复用同一个实例，完全避免重复初始化对象的开销，特别适合数据库、云存储这类连接建立成本高的服务客户端。
• 实现简单：代码逻辑直观，无需额外依赖注入相关代码，直接创建实例后在端点中调用即可。

缺点 #

• 灵活性不足：无法根据请求上下文（如不同用户、租户的差异化配置）动态调整客户端实例，全局实例是固定的。
• 测试难度大：单元测试时难以替换全局实例，只能通过mock全局变量的方式实现，容易引发测试用例之间的污染。
• 生命周期不可控：若客户端需要在应用 shutdown 时执行资源清理（如关闭连接池），需要手动编写额外的生命周期钩子处理，无法借助FastAPI的原生机制。

依赖注入方案 #

首先需要纠正一个常见误解：依赖注入并不意味着每次请求都要创建新的客户端实例。通过合理编写依赖函数，完全可以实现单例复用，同时保留依赖注入的优势。

优化后的依赖注入示例（单例复用） #

from fastapi import APIRouter, Depends

router = APIRouter()

# 维护单例客户端实例
_client_instance = None

def get_client():
    global _client_instance
    if _client_instance is None:
        _client_instance = SomeClient()
    yield _client_instance
    # 可选：在这里添加请求结束后的资源清理逻辑

@router.get("/")
def hello(client: SomeClient = Depends(get_client)):
    client.do_something()
    return "hello"

优点 #

• 可测试性强：测试时可以轻松替换依赖，比如编写一个返回mock客户端的依赖函数，直接注入到端点中，无需修改业务代码。
• 原生生命周期管理：通过生成器类型的依赖函数，FastAPI会自动在请求结束后执行yield后的逻辑，方便处理资源清理（如关闭连接、释放句柄）。
• 上下文感知能力：可以根据请求的上下文信息（如请求头、路径参数）动态创建或选择对应的客户端实例，适配多租户、多环境等复杂场景。
• 代码解耦：端点代码不直接依赖客户端的创建逻辑，后续修改客户端的初始化方式（如添加配置参数、切换服务提供商）时，仅需修改依赖函数，无需改动所有使用该客户端的端点。

缺点 #

• 配置不当会有性能开销：如果依赖函数未做单例处理，每次请求都创建新实例，会增加对象初始化的成本。但这个问题可以通过上述单例模式轻松解决。
• 初期复杂度略高：相比全局实例，需要额外编写依赖函数，对FastAPI依赖注入机制有一定学习成本。

何时选择依赖注入 #

• 需要进行单元测试：依赖注入是实现可测试代码的关键，能让你快速替换真实服务为mock，提升测试效率和可靠性。
• 客户端需要生命周期管理：当客户端需要在请求结束后清理资源，或在应用启动/ shutdown时执行初始化/销毁逻辑时，依赖注入的原生机制能简化这一过程。
• 需要动态适配请求上下文：多租户、多环境等场景下，依赖注入可以根据请求信息动态返回对应配置的客户端实例。
• 项目规模较大、需要维护性：当多个端点依赖同一个客户端时，依赖注入可以统一管理客户端的创建逻辑，避免重复代码，降低维护成本。

总结 #

如果你的场景简单，仅需要单实例复用，且无需测试、动态调整或生命周期管理，全局初始化方案是更简单直接的选择；但如果涉及测试、复杂生命周期管理、上下文适配或代码解耦需求，依赖注入是更优的方案——而且通过合理配置依赖函数，完全可以实现单例复用，不会损失性能。

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