为什么我用 FastAPI 而不是 Django 做小程序后端

刚开始做微信小程序后端时，我理所当然地想到了 Django——毕竟“Python Web 框架”几个字最容易联想到的就是它。但真正动手对接小程序之后，我换成了 FastAPI，并且一直用到现在。这里把我换框架的真实理由讲清楚，供同样处境的人参考。

一、小程序后端天然是“异步 + 外部调用”模型

小程序后端很少自己算重逻辑，更多是“接微信接口、查数据库、再返回”。而微信的 code2session、内容安全检测、模板消息，全都是外部 HTTP 调用。FastAPI 基于 ASGI，原生支持 async/await，在等待这些外部请求时不会阻塞事件循环，单进程就能扛住更高的并发。

二、Pydantic 让接口“自带校验”

小程序前端传来的字段五花八门，与其在每个接口里手写一堆 if not field 判断，不如直接声明数据模型。FastAPI 用 Pydantic 做请求体校验，参数不对会直接返回清晰的错误，后端代码干净很多：

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class IssueIn(BaseModel):
    title: str
    category: str

@app.post("/api/issues")
async def create_issue(payload: IssueIn):
    # 字段类型与必填已由 Pydantic 保证
    return {"ok": True, "title": payload.title}

三、自带 Swagger 文档，联调效率翻倍

做小程序最烦的就是和前端对接口。FastAPI 自动生成 /docs 交互式文档，字段、类型、示例一目了然，前端同事直接照着填就能调，省掉大量口头沟通。

四、不需要 Django 那一套“全家桶”

Django 的 ORM、Admin、表单都很强，但我的后台管理是另做的，数据库也大量用到原生 SQL 和存储过程。Django 的“重”在这里反而成了负担。FastAPI 只做它擅长的——把 HTTP 层做好，其余交给我自己选的组件。

经验提醒：异步接口里千万别调用阻塞型库（比如普通 requests 同步请求），否则事件循环会被卡住，性能反而比同步框架还差。要么用 httpx.AsyncClient，要么把阻塞调用丢进线程池。

五、什么时候还是该用 Django

如果你需要开箱即用的后台管理、用户权限体系，或者团队里大家都熟 Django，那它依然是最好的选择。框架没有高下，只有合不合适。我的场景是“轻后端 + 重外部交互 + 自研管理台”，所以 FastAPI 更对路。

下一篇我会写怎么用 Docker 把这套 FastAPI 服务一键部署到服务器，让“能跑在本地”变成“能稳定对外服务”。