1. 引言:由于“太快”而带来的烦恼
你是否经历过这样的场景?
周五下午,你兴致勃勃地用 pip install fastapi 开启了一个新项目。main.py 里只有 20 行代码,一切都跑得飞快,你觉得自己像个风一样的男子。
然而,两周后,情况变了。
那个曾经清秀的 main.py 膨胀到了 2000 行。数据库连接、Pydantic 模型、路由逻辑、鉴权代码全部纠缠在一起。你想修改一个用户的 API,结果不小心弄崩了商品的查询功能。此时的你,面对着屏幕上那一坨“意大利面条代码”(Spaghetti Code),只想把它关掉回家睡觉。
FastAPI 的“快”是双刃剑。 它不强制你遵循特定的结构,但这不代表你不需要结构。今天,我们就来谈谈如何通过合理的架构模式和最佳实践,将你的 FastAPI 项目打造成一座稳固、可扩展的摩天大楼。
2. 概念拆解:如果你是公司的 CEO
为了理解为什么我们需要分层架构,我们来打个比方。
想象你开了一家初创公司(这就是你的 App)。
-
初创阶段(单文件模式):整个公司只有你一个人。你是 CEO,也是销售,还是保洁阿姨。所有事情你都亲力亲为(所有逻辑都在
main.py)。这在创业初期(Demo)没问题,效率极高。 -
扩张阶段(生产级架构):业务做大了,你不能再自己扫地了。你需要组建部门:
-
销售部 专门负责拉客(
Routers:处理路由请求)。 -
后勤部 专门负责物资(
Schemas:定义数据格式)。 -
技术部 专门负责底层设施(
Database/CRUD:处理数据库交互)。 -
外包团队 随叫随到,按需服务(
Dependencies:依赖注入)。
-
这就是我们今天要讲的核心:关注点分离(Separation of Concerns)。
FastAPI 提供了两个最强大的武器来实现这一目标:APIRouter(部门拆分) 和 Dependency Injection(按需服务)。
3. 动手实战:重构你的 main.py
我们要做的第一件事,就是肢解那个臃肿的 main.py。
3.1 理想的文件结构
不要把鸡蛋放在一个篮子里。一个标准的生产级目录结构应该长这样:
/* by 01130.hk - online tools website : 01130.hk/zh/gifcompression.html */
/app
/routers # 销售部:处理路径和请求
users.py
items.py
/schemas # 后勤部:Pydantic 模型(数据契约)
user.py
item.py
/crud # 技术部:数据库操作逻辑
user.py
/core # 核心配置
config.py
main.py # CEO:统筹全局
3.2 路由拆分(APIRouter)
假设我们要把用户相关的逻辑拆出去。
第一步:创建分部(app/routers/users.py)
/* by 01130.hk - online tools website : 01130.hk/zh/gifcompression.html */
from fastapi import APIRouter
# 这里的 prefix="/users" 意味着所有在这个路由下的路径都会自动加上 /users 前缀
# tags=["users"] 用于在 Swagger UI 文档中分组
router = APIRouter(prefix="/users", tags=["users"])
@router.get("/")
async def read_users():
return [{"username": "Rick"}, {"username": "Morty"}]
@router.get("/me")
async def read_user_me():
return {"username": "fakecurrentuser"}
第二步:总部汇报(app/main.py)
CEO 需要知道有哪些部门存在。
from fastapi import FastAPI
from app.routers import users, items # 假设你也有 items
app = FastAPI()
# 将分部的路由注册到主应用中
app.include_router(users.router)
# app.include_router(items.router)
@app.get("/")
async def root():
return {"message": "Hello World"}
代码解析:
-
APIRouter就像是一个微型的FastAPI实例。 -
app.include_router就像是插线板,把各个模块的插头插到主电源上。 -
为什么这么做? 你的
main.py再次变回了清爽的状态,而且多人协作时,你写users,我写items,互不冲突。
4. 进阶深潜:三个你必须遵守的“军规”
仅仅拆分文件还不够,这里有三个区分“新手”和“老鸟”的关键细节。
军规一:输入与输出模型分离 (DTO Pattern)
很多新手会直接把数据库模型(ORM Model)返回给前端,这是大忌!这会导致你把用户的密码哈希值也一并泄露出去。
最佳实践:使用不同的 Pydantic 模型分别对应“请求”和“响应”。
# app/schemas/user.py
from pydantic import BaseModel, EmailStr
# 1. 用户注册时填写的(包含密码)
class UserCreate(BaseModel):
username: str
password: str
email: EmailStr
# 2. 返回给前端展示的(绝对不能包含密码!)
class UserResponse(BaseModel):
id: int
username: str
email: EmailStr
class Config:
from_attributes = True # 允许从 ORM 模型读取数据
在路由中使用:
@router.post("/", response_model=UserResponse) # 明确告诉 FastAPI 使用哪个模型过滤返回值
async def create_user(user: UserCreate):
# 这里处理创建逻辑...
# return db_user_object
# FastAPI 会自动根据 UserResponse 过滤掉 db_user_object 中的 password 字段
pass
军规二:依赖注入是你的救命稻草 (Dependency Injection)
不要在全局范围内初始化数据库连接或复杂的逻辑对象。使用 Depends。
错误示范(全局变量):
db = SessionLocal() # 危险!连接可能断开,或者在并发时混乱
@app.get("/users")
def get_users():
return db.query(User).all()
正确示范(依赖注入):
# app/dependencies.py
def get_db():
db = SessionLocal()
try:
yield db
finally:
db.close() # 确保请求结束后关闭连接
# 在路由中使用
from fastapi import Depends
from sqlalchemy.orm import Session
@router.get("/users")
def get_users(db: Session = Depends(get_db)): # 只有在这个请求进来时,才会创建连接
return crud.get_users(db)
为什么?
-
安全性:
finally块确保了即使发生错误,数据库连接也能正确关闭。 -
可测试性:写单元测试时,你可以轻松地用
app.dependency_overrides把真实的数据库替换成 Mock 对象,而不需要去 hack 全局变量。
军规三:配置管理不要硬编码
不要把 SECRET_KEY 或数据库 URL 写死在代码里。使用 pydantic-settings 读取环境变量。
# app/core/config.py
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
database_url: str
secret_key: str
debug: bool = False
class Config:
env_file = ".env"
settings = Settings()
这样,你的代码在开发环境、测试环境和生产环境之间切换时,只需要更换 .env 文件,而不需要改动任何一行代码。
5. 总结与延伸
总结
FastAPI 的最佳实践核心在于**“秩序”**:
-
使用 APIRouter 拆分业务逻辑,别让
main.py成为垃圾场。 -
严格区分 Pydantic Schemas(输入/输出)和 ORM Models(数据库),保护数据安全。
-
利用 Dependency Injection 管理数据库会话和共享逻辑,提升可测试性。
1万+

被折叠的 条评论
为什么被折叠?



