首页 > 其他资讯 > FastAPI 依赖注入被你用成了全局变量？别慌，三分钟讲透

FastAPI 依赖注入被你用成了全局变量？别慌，三分钟讲透

时间：26-04-23

一、你可能正在这样写

先做个快速自查，看看你的代码是否踩中了这些典型陷阱。检查你的FastAPI项目，如果存在以下任何一种模式，那么你的依赖注入很可能已经退化为隐形的全局状态管理。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

写法一：在依赖函数里塞了个列表，全项目共享状态

from fastapi import FastAPI, Depends

app = FastAPI()

# 这玩意儿叫“全局变量”，不叫“依赖注入”
cache = []

@app.get("/items")
async def get_items():
    cache.append("data")
    return {"cache": cache}

写法二：在路由函数里直接 import 一个单例，假装在用依赖注入

from fastapi import FastAPI, Depends

app = FastAPI()

class Database:
    def __init__(self):
        self.connection = "I'm a global db!"

db = Database()  # 这行代码，值得警惕

@app.get("/items")
async def get_items(database: Database = Depends(lambda: db)):
    return database.connection

写法三：在依赖函数里保存了上一次请求的状态

from fastapi import FastAPI, Depends

app = FastAPI()

def get_user():
    # 每次请求，上一个用户的数据还留着
    user_data = {"name": "last_user"}
    return user_data

@app.get("/profile")
async def profile(user = Depends(get_user)):
    return user

如果你的代码完美避开了上述所有情况，值得肯定：要么你已深谙其道，要么项目复杂度尚未暴露问题。如果命中——不必焦虑，继续阅读，三分钟帮你重构思路。

二、依赖注入到底是什么

在修正错误之前，必须建立正确的认知框架。

FastAPI的依赖注入，本质是一个请求作用域的工厂模式。每次HTTP请求到达，框架都会重新执行这个工厂函数，将生成的对象注入目标路由。请求处理完毕，该对象生命周期随之终结。

类比医院采血流程：每位患者使用一套独立的全新器械。你完成采样离开，护士会为下一位患者准备另一套未使用的工具。

依赖注入遵循相同逻辑——每个请求获得专属的、隔离的对象实例，互不污染。

全局变量则截然不同：如同采血后器械留在原处，下一位患者可能接触到残留样本。

这就是FastAPI依赖注入的核心机制：请求级隔离，自动资源回收。

三、正确的打开方式

场景一：数据库连接（最常见）

from fastapi import FastAPI, Depends
from sqlalchemy.orm import Session

# 每次请求进来，创建新的连接；请求结束，自动关闭
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@app.get("/users/{user_id}")
async def get_user(user_id: int, db: Session = Depends(get_db)):
    return db.query(User).filter(User.id == user_id).first()

关键点：yield语句是资源管理的核心——yield前的代码在请求入口执行，yield后的代码在请求出口执行，确保连接自动关闭，无资源泄漏。

场景二：用户认证（链式依赖）

from fastapi import Depends, HTTPException

# 第一层：提取 Token
def get_token(token: str = Header(None)):
    if not token:
        raise HTTPException(status_code=401, detail="未登录")
    return token

# 第二层：验证 Token，返回用户信息
def get_current_user(token: str = Depends(get_token)):
    user = verify_jwt(token)
    if not user:
        raise HTTPException(status_code=401, detail="Token 无效")
    return user

# 在路由中使用，依赖链自动解析
@app.get("/profile")
async def profile(user = Depends(get_current_user)):
    return {"username": user.username}

关键点：get_current_user显式依赖get_token，FastAPI自动解析执行顺序。路由函数仅需声明最终依赖，逻辑分层清晰，符合单一职责原则。

场景三：应用级全局依赖（跨所有路由）

from fastapi import FastAPI, Depends, Header, HTTPException

async def verify_api_key(x_api_key: str = Header(...)):
    if x_api_key != "your-secret-key":
        raise HTTPException(status_code=403, detail="API Key 不对")
    return x_api_key

# 加在 app 上，所有路由都要过这关
app = FastAPI(dependencies=[Depends(verify_api_key)])

@app.get("/items")
async def read_items():
    return [{"item": "Portal Gun"}]

@app.get("/users")
async def read_users():
    return [{"username": "Rick"}]

关键点：通过app = FastAPI(dependencies=[...])声明全局依赖，适用于API密钥校验、统一日志记录等横切关注点，确保所有路由通过统一验证层。

四、什么时候真的可以用“全局变量”

客观而言，在两种特定场景下，使用全局对象是安全且合理的：

情况一：配置参数（不涉及请求状态）

from fastapi import FastAPI

app = FastAPI()

# 写死的配置常量，不是请求状态，完全 OK
MAX_PAGE_SIZE = 100
DEFAULT_TIMEOUT = 30

情况二：Lru_cache 缓存（读写分离，明确知道自己在干什么）

from functools import lru_cache

@lru_cache()
def get_config():
    # 应用启动时加载一次，整个进程生命周期内不变
    return load_config_from_file()

@lru_cache()
def get_redis_client():
    # 连接池，通常在应用启动时建立，不随请求创建/销毁
    return redis.Redis(host="localhost")

遵循一个简单原则：任何与请求上下文相关的数据（用户会话、认证令牌、请求参数），必须通过Depends管理。应用级配置、只读缓存或连接池，才是全局变量的合理应用领域。