web框架（Django 与 FastAPI）

发表于 2025-6-14 18:31:35

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？立即注册

×

注：本文是python的学习条记；不是教程！不是教程！内容可能有所疏漏，欢迎交流指正。

一：根本先容

1. Django（全栈Web框架）

Django 是一个成熟的、全功能 Python Web 框架，遵循"电池已包含"的理念，提供了构建 Web 应用所需的几乎全部组件。
核心特点：

完整解决方案：提供从数据库到前端的完整开发工具链
约定优于配置：通过公道的默认设置淘汰配置工作
快速开发：内置管理后台、用户认证、表单处理等常用功能
企业级稳定性：经过十多年的生产环境验证

实用场景：

内容管理体系（CMS）
电商网站
企业级Web应用
必要快速原型开发的项目

2. FastAPI（现代API框架）

FastAPI 是一个现代的高性能 Web 框架，专为 API 开发而计划，以速率快、代码轻巧和自动生成 API 文档为特色。
核心特点：

极高性能：基于Starlette和Pydantic，性能接近Node.js和Go
范例安全：基于Python范例注解的自动数据验证和序列化
自动文档：自动生成交互式 API 文档
异步优先：从底层计划就支持异步编程模式

实用场景：

RESTful API 服务
微服务架构
及时应用
呆板学习模子部署

二：架构计划

1. Django 架构

Django 采用 MVT (Model-View-Template) 架构
架构组件详解：

Model（模子层）
- 负责数据定义和业务逻辑
- 通过Django ORM与数据库交互
- 定义数据结构、关系和约束
- 处理数据验证和业务规则
View（视图层）
- 处理HTTP哀求和响应
- 包含业务逻辑的控制器
- 调用Model获取数据
- 选择符合的Template进行渲染
Template（模板层）
- 负责数据的展示和用户界面
- 使用Django模板语言进举措态内容渲染
- 分离逻辑和展示层

哀求处理流程：
用户哀求 → URL 路由 → 视图函数 → 模子交互 → 模板渲染 → 响应

Django 的主要组件

ORM：对象关系映射体系，处理数据库交互
URL 分发器:：将 URL 模式映射到视图函数
模板体系：用于生成 HTML
表单处理：处理用户输入和验证
Admin 后台：自动生成管理界面
中央件：处理哀求和响应的钩子体系

2. FastAPI 架构

FastAPI 建立在 Starlette 和 Pydantic 之上
核心依靠剖析：

Starlette
- 提供ASGI服务器支持
- 处理HTTP和WebSocket协议
- 提供路由、中央件等基础Web功能
- 支持异步利用和高性能处理
Pydantic
- 基于Python范例注解的数据验证
- 自动数据序列化和反序列化
- 提供具体的错误信息
- 生成JSON Schema

哀求处理流程：
用户哀求 → 路由匹配 → 依靠注入 → 路径利用函数 → 响应序列化 → 响应

FastAPI 的主要组件

Starlette：提供 ASGI 服务器支持和基础 Web 功能
Pydantic：提供数据验证和序列化
依靠注入体系：管理组件依靠
OpenAPI：自动生成 API 文档

三、实行模子：同步 vs 异步

1. Django：同步实行模子

同步实行是传统的程序实行模式：

顺序实行：代码按照编写顺序逐行实行，每一行代码必须完成后才能实行下一行
阻塞利用：当程序碰到 I/O 利用（如网络哀求、文件读写、数据库查询）时，整个线程会制止并等候利用完成
资源利用率低：等候 I/O 时，CPU 实际上是空闲的，线程/历程资源被占用但无法处理其他任务

# Django 视图示例 - 同步模式
def user_profile(request, user_id):
# 数据库查询会阻塞线程, 直到查询完成
user = User.objects.get(id=user_id)
# 当前线程被阻塞无法处理其他请求, 直到上一步执行完成得到结果（或失败）再继续执行后续代码
return render(request, 'profile.html', {'user': user})

复制代码

Django 默认使用 WSGI (Web Server Gateway Interface) 服务器接口，采用同步实行模子:

历程/线程模子：每个HTTP哀求由一个独立的线程处理
阻塞特性：I/O利用会阻塞当前线程，直到利用完成
并发限制：并发处理本领受限于可用的线程数目
内存开销：每个线程必要独立的内存空间（通常2-10MB）

同步模子的优缺点：
优点：

编程模子简朴，易于明白和调试
错误处理直观，异常传播清晰
与传统数据库和库兼容性好
成熟稳定，经过长期验证

缺点：

I/O密集型应用性能受限
高并发场景下资源利用率低
扩展性依靠于增加历程/线程数目

2. FastAPI：异步实行模子

异步实行是一种现代的程序实行模式，允许程序在等候I/O利用时继承实行其他任务：

非阻塞实行：碰到I/O利用时不等候，立刻切换实行其他可用任务
事件循环：核心机制是一个事件循环，管理全部未完成的任务
协程：可以暂停和恢复的特殊函数，是异步编程的根本单元

协程的本质
协程（Coroutine）是一种可以暂停和恢复的特殊函数，具有以下特点：

可暂停实行：协程可以在实行过程中暂停，并在之后恢复
保存实行状态：暂停时，协程的本地变量和实行状态会被保存
协作式多任务：协程自己决定何时让出控制权（使用 await）

# FastAPI 路径操作函数 - 异步模式
@app.get("/users/{user_id}")
async def get_user(user_id: int):
# 异步数据库查询，不会阻塞线程
user = await database.query(f"SELECT * FROM users WHERE id = {user_id}")
# await 暂停当前协程（函数），让出控制权给事件循环，允许处理其他请求
return {"user": user}

复制代码

FastAPI 使用 ASGI (Asynchronous Server Gateway Interface) 服务器接口，支持异步实行:

单线程多任务：一个线程可以同时处理多个哀求
事件驱动：基于事件循环的调治机制
高并发本领：可以处理数千个并发毗连
低内存占用：协程的内存开销远小于线程

异步模子的优缺点：
优点：

I/O密集型应用性能优异
高并发处理本领强
资源利用率高
适当现代微服务架构

缺点：

编程复杂度较高
调试相对困难
必要异步兼容的库和工具
CPU密集型任务无显着上风

四、哀求处理流程

1. Django 哀求生命周期

接收哀求：WSGI 服务器接收 HTTP 哀求
中央件处理：哀求预处理（身份验证、会话等）
URL 剖析：匹配 URL 与视图函数
视图实行：实行视图函数，可能涉及:
- 表单处理
- 数据库查询 (ORM)
- 业务逻辑
模板渲染：生成 HTML 响应
中央件后处理：响应后处理
返反响应：将响应发送回客户端

2. FastAPI 哀求生命周期

接收哀求：ASGI 服务器接收 HTTP 哀求
路由匹配：识别匹配的路径利用函数
参数剖析与验证：
- 路径参数、查询参数、哀求体自动剖析
- Pydantic 模子验证哀求数据
依靠注入：剖析和注入依靠项
实行路径利用函数：处理哀求逻辑
响应处理：
- 自动序列化响应数据
- 生成 JSON/HTML 等响应
返反响应：将响应发送回客户端

五、数据库交互对比

1. Django ORM

# Django ORM 示例
from django.db import models
class User(models.Model):
name = models.CharField(max_length=100)
email = models.EmailField(unique=True)
# 数据查询
users = User.objects.filter(name__startswith="张").order_by("email")

复制代码

Django ORM 特点:

完整的 ORM 体系，处理关系型数据库
迁移体系，自动生成数据库 schema
丰富的查询 API
关系处理（一对一、一对多、多对多）
同步利用，不支持原生异步

2. FastAPI 数据库处理

FastAPI 没有内置 ORM，通常使用以下方案:
SQLAlchemy

# 使用 SQLAlchemy 的同步版本
from sqlalchemy import Column, Integer, String, create_engine
from sqlalchemy.ext.declarative import declarative_base
Base = declarative_base()
class User(Base):
__tablename__ = "users"
id = Column(Integer, primary_key=True)
name = Column(String)
email = Column(String)
# 使用 SQLAlchemy 异步版本
from sqlalchemy.ext.asyncio import create_async_engine, AsyncSession
async def get_user(user_id: int):
async with AsyncSession(engine) as session:
result = await session.execute(select(User).where(User.id == user_id))
return result.scalars().first()

复制代码

Tortoise ORM (异步 ORM）

from tortoise import Model, fields
class User(Model):
id = fields.IntField(pk=True)
name = fields.CharField(max_length=255)
email = fields.CharField(max_length=255)
# 异步查询
user = await User.filter(name__startswith="张").first()

复制代码

FastAPI 数据库处理特点

机动选择 ORM 或直接使用数据库驱动
支持异步数据库利用
与 Pydantic 模子无缝集成

六、性能与并发处理

1. Django 性能特点

成熟稳定，适当复杂应用
同步实行模子限制了高并发性能
使用多历程/多线程扩展（如 Gunicorn）
对于 I/O 密集型利用服从较低
内置缓存体系，提高性能

性能上风：

成熟稳定，经过大规模生产验证
内置缓存体系（内存、数据库、文件、Redis等）
数据库查询优化工具（select_related、prefetch_related）
静态文件处理和CDN集成

性能限制：

同步实行模子限制了I/O密集型应用的性能
每个哀求必要独立线程，内存开销较大
GIL（全局解释器锁）限制了CPU密集型任务的并行处理

并发处理策略：

多历程部署：使用Gunicorn等WSGI服务器
负载均衡：通过Nginx等反向署理分发哀求
缓存策略：淘汰数据库查询和盘算开销
异步任务：使用Celery处理后台任务

Django 3.1+ 开始支持 ASGI，但大部分功能仍是同步的

# Django 中使用有限的异步支持
async def my_view(request):
# 可以使用异步操作，但与 ORM 等同步组件交互仍有限制
await asyncio.sleep(1)
return HttpResponse("Hello")

复制代码

2. FastAPI 性能特点

极高的性能，接近 Node.js 和 Go
异步实行模子，高效处理并发
单线程处理多哀求，淘汰资源斲丧
基于 Uvicorn/Starlette 的高效 ASGI 服务器
适当高 I/O 场景（如微服务、API）

性能上风：

异步实行模子，I/O密集型应用性能优异
基于Starlette和Pydantic的高效实现
单线程处理多哀求，内存占用低
接近Node.js和Go的性能水平

性能测试数据：

在相同硬件条件下，FastAPI的吞吐量通常是Django的2-10倍
响应时间更低，特殊是在高并发场景下
内存使用服从更高

并发处理上风：

事件循环：单线程处理数千个并发毗连
协程调治：高效的任务切换机制
异步I/O：网络和数据库利用不阻塞
WebSocket支持：原生支持及时通信

FastAPI 性能上风示例

@app.get("/items/")
async def read_items():
# 多个异步 I/O 操作可以并发执行
results = await asyncio.gather(
fetch_from_database(),
call_external_api(),
send_notification()
)
return {"results": results}

复制代码

七、路由与哀求处理对比

1. Django 路由体系

# urls.py
from django.urls import path
from . import views
urlpatterns = [
path('users/<int:user_id>/', views.user_detail),
path('users/', views.user_list),
]
# views.py
def user_detail(request, user_id):
if request.method == 'GET':
# 处理 GET 请求
elif request.method == 'POST':
# 处理 POST 请求
# ...

复制代码

Django 路由特点

集中式 URL 配置
基于正则表达式的路由匹配
手动处理 HTTP 方法分发
哀求参数需手动剖析和验证

2. FastAPI 路由体系

from fastapi import FastAPI, Path, Query, Body
from pydantic import BaseModel
app = FastAPI()
class User(BaseModel):
name: str
email: str
@app.get("/users/{user_id}")
async def get_user(
user_id: int = Path(..., gt=0),
q: str = Query(None, max_length=50)
):
return {"user_id": user_id, "query": q}
@app.post("/users/")
async def create_user(user: User):
return user

复制代码

FastAPI 路由特点

装饰器定义路由
自动 HTTP 方法分发
自动参数剖析和范例验证
基于范例注解的参数处理
OpenAPI 文档自动生成

八、中央件与依靠注入

1. Django 中央件

中央件特点：

洋葱模子的处理机制
全局应用于全部哀求
处理横切关注点（认证、日记、缓存等）
按顺序实行，支持哀求和响应处理

常用中央件：

SecurityMiddleware：安全相关设置
SessionMiddleware：会话管理
AuthenticationMiddleware：用户认证
CsrfViewMiddleware：CSRF保护

# Django 中间件示例
class SimpleMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
# 请求前处理
print("处理请求前")
response = self.get_response(request)
# 响应后处理
print("处理响应后")
return response

复制代码

Django 使用类似洋葱模子的中央件体系

中央件按序实行
全局应用于全部哀求
处理认证、会话、安全等横切关注点

2. FastAPI 依靠注入

依靠注入上风：

声明式依靠管理
支持嵌套和递归依靠
自动剖析依靠顺序
支持依靠缓存和作用域

依靠注入应用：

认证和授权：用户身份验证
数据库毗连：管理数据库会话
配置注入：应用配置参数
服务注入：外部服务客户端

from fastapi import Depends, FastAPI, HTTPException
app = FastAPI()
async def verify_token(token: str):
if token != "valid_token":
raise HTTPException(status_code=401)
return token
async def get_current_user(token: str = Depends(verify_token)):
return {"user": "current_user"}
@app.get("/users/me")
async def read_users_me(current_user: dict = Depends(get_current_user)):
return current_user

复制代码

FastAPI 依靠注入体系

可重用、可嵌套的依靠项
声明式依靠管理
范围控制（哀求级、应用级）
自动处理依靠剖析顺序
测试友好，易于模仿依靠

九、模板与前端集成

1. Django 模板体系

{% extends "base.html" %}
{% block content %}
<h1>{{ user.name }}</h1>
<ul>
{% for post in posts %}
<li>{{ post.title }}</li>
{% endfor %}
</ul>
{% endblock %}

复制代码

传统服务端渲染：

内置强盛的模板体系
支持模板继承和组件化
自动HTML转义和安全处理
与Django表单体系深度集成

现代前端集成：

Django REST Framework提供API
支持前后端分离架构
可以与React、Vue等框架共同

2. FastAPI 前端集成

FastAPI 主要关注 API 开发，前端渲染选项:
Jinja2 模板 (必要额外安装)

from fastapi import FastAPI, Request
from fastapi.templating import Jinja2Templates
app = FastAPI()
templates = Jinja2Templates(directory="templates")
@app.get("/items/{id}")
async def read_item(request: Request, id: str):
return templates.TemplateResponse(
"item.html", {"request": request, "id": id}
)

复制代码

与前端框架集成

# FastAPI 提供 API，前端框架消费 API
@app.get("/api/users")
async def get_users():
users = await db.fetch_all("SELECT * FROM users")
return users # 自动转为 JSON

复制代码

API优先计划：

专注于提供高质量的API服务
自动生成交互式API文档
支持多种响应格式（JSON、XML、HTML）
完美适配前后端分离架构

模板支持：

可选集成Jinja2模板引擎
支持服务端渲染需求
机动的响应范例处理

十、安全特性对比

1. Django 安全特性

内置安全机制：

CSRF保护：防止跨站哀求伪造
XSS防护：自动HTML转义
SQL注入防护：ORM参数化查询
点击劫持保护：X-Frame-Options头
安全中央件：HTTPS重定向、安全头设置

认证和授权：

内置用户认证体系
权限和组管理
会话管理
密码哈希和验证

Django 安全示例

# Django 内置认证系统
from django.contrib.auth.decorators import login_required
@login_required
def profile_view(request):
# 只有登录用户可访问
return render(request, 'profile.html')

复制代码

2. FastAPI 安全特性

现代安全实践：

OAuth2和JWT支持
基于依靠注入的安全机制
CORS支持
输入验证防止注入攻击

安全工具集成：

与Python安全库无缝集成
支持多种认证方案
机动的权限控制

FastAPI 安全示例

from fastapi import Depends, FastAPI, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")
@app.get("/users/me")
async def read_users_me(token: str = Depends(oauth2_scheme)):
user = get_user_from_token(token)
if not user:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Invalid authentication credentials"
)
return user

复制代码

十一、扩展性与生态体系

1. Django 生态体系

大量第三方应用 (Django REST Framework, Django Channels 等)
插件体系
成熟的社区支持
完整的文档和教程
企业级支持

2. FastAPI 生态体系

与 Python 异步生态体系集成
扩展库较少但增长迅速
简朴的扩展机制
活泼的社区
与现代开发工具集成（Docker, CI/CD 等）

十二、使用场景建议

1. 适当 Django 的场景

内容管理体系
大型企业应用
必要管理后台的应用
数据库密集型应用
传统的服务器渲染网站
必要快速开发完整应用的场景

2. 适当 FastAPI 的场景

微服务架构
高性能 API 开发
及时应用（WebSocket）
数据科学/呆板学习 API
前后端分离架构
高并发、I/O 密集型应用

十四、结论与选择建议

1. Django 上风

全功能框架，提供完整解决方案
强盛的 ORM 和管理后台
丰富的生态体系和插件
美满的文档和社区支持
稳定性和可维护性

2. FastAPI 上风

杰出的性能和并发处理本领
异步支持，高效处理 I/O 密集型任务
现代 Python 特性（范例注解、异步）
自动 API 文档生成
轻巧的代码风格

3. 如何选择

选择 Django 假如:
- 必要构建完整的网站而非仅 API
- 必要现成的管理后台
- 优先考虑开发速率和成熟度
- 团队熟悉传统 Web 开发
选择 FastAPI 假如:
- 主要构建 API 服务
- 性能和并发处理是关键
- 必要处理大量 I/O 利用
- 喜欢现代 Python 特性
- 构建微服务架构
混淆使用:
- 对现有 Django 项目添加高性能 API 端点
- 使用 FastAPI 开发微服务，Django 开发管理体系

十五、WSGI 与 ASGI 深度剖析

1. WSGI (Web Server Gateway Interface)

WSGI 是 Python Web 应用与 Web 服务器之间的尺度接口
根本工作原理

def wsgi_application(environ, start_response):
# environ: 包含请求信息的字典
# start_response: 用于发送响应状态和头部的回调函数
status = '200 OK'
headers = [('Content-Type', 'text/plain')]
start_response(status, headers)
# 返回响应体（必须是可迭代对象）
return [b'Hello, World!']

复制代码

同步处理模子

一个哀求由一个线程/历程处理
处理过程中，该线程/历程被占用直到哀求完成
多个并发哀求必要多个线程/历程

流程图

# 客户端请求 → Web服务器 → WSGI服务器 → WSGI应用（调用一次）→ 响应

复制代码

2. ASGI (Asynchronous Server Gateway Interface)

ASGI 是 WSGI 的异步演进，支持 WebSocket 等长毗连协议
根本工作原理

async def asgi_application(scope, receive, send):
# scope: 包含连接类型和请求信息的字典
# receive: 异步函数，用于接收消息
# send: 异步函数，用于发送消息
if scope['type'] == 'http':
# 处理 HTTP 请求
message = await receive() # 接收请求
# 发送响应
await send({
'type': 'http.response.start',
'status': 200,
'headers': [(b'content-type', b'text/plain')],
})
await send({
'type': 'http.response.body',
'body': b'Hello, World!',
})

复制代码

异步处理模子

单个历程可以同时处理多个哀求
基于事件循环和协程
I/O 利用不会阻塞整个服务器

流程图

# 客户端请求 → Web服务器 → ASGI服务器 → ASGI应用（可能多次调用）→ 响应

复制代码

3. 服务器实现与部署

1. Django 的服务器选项

Gunicorn (Green Unicorn)
Gunicorn 是一个 WSGI HTTP 服务器，实用于 Django：

预分叉工作模子：主历程（master）管理多个工作历程（worker）

历程与线程配置

# 启动 4 个工作进程
gunicorn myapp.wsgi:application --workers=4
# 每个工作进程有 2 个线程
gunicorn myapp.wsgi:application --workers=4 --threads=2

复制代码

工作原理

主历程接收哀求并分发给工作历程
每个工作历程独立处理分配给它的哀求
工作历程崩溃时，主历程会重启它

内部架构

主进程（Master）
│
├── 工作进程 1（Worker）── 线程 1
│ └── 线程 2
│
├── 工作进程 2（Worker）── 线程 1
│ └── 线程 2
│
└── ...

复制代码

uWSGI
uWSGI 是另一个流行的 WSGI 服务器：

多种历程模子：支持预分叉、动态、Emperor 等多种模式

历程与线程配置

# uwsgi.ini 配置文件
[uwsgi]
processes = 4 # 工作进程数
threads = 2 # 每个进程的线程数

复制代码

高级特性

内置负载均衡
历程监控和自动恢复
内存优化

2. FastAPI 的服务器选项

Uvicorn
Uvicorn 是一个基于 uvloop 和 httptools 的 ASGI 服务器：

基于事件循环：使用 uvloop（Cython 实现的 asyncio 事件循环，比尺度库更快）

历程模子配置

# 单进程模式
uvicorn app:app
# 多进程模式（使用 Gunicorn 作为进程管理器）
gunicorn app:app -w 4 -k uvicorn.workers.UvicornWorker

复制代码

内部架构

Uvicorn 进程
│
└── 事件循环
│
├── 协程 1（处理请求 A）
│
├── 协程 2（处理请求 B）
│
└── ...

复制代码

工作原理

启动事件循环
接收哀求并创建协程处理
协程在等候 I/O 时让出控制权
事件循环管理全部运行中的协程

十六、深入明白同步、异步模子

1. Django 同步模子

1. Django 的哀求处理机制

Django 默认使用同步处理模子

# Django 视图基本结构
def view_function(request):
# 1. 读取请求数据
user_id = request.GET.get('user_id')
# 2. 进行数据库查询（阻塞操作）
user = User.objects.get(id=user_id)
# 3. 可能进行外部 API 调用（阻塞操作）
user_stats = requests.get(f"https://api.example.com/stats/{user_id}")
# 4. 模板渲染（CPU 操作）
return render(request, 'user.html', {'user': user, 'stats': user_stats.json()})

复制代码

2. Django 中的历程与线程

在典型 Django 部署中：
每个历程：

加载完整的 Django 应用
包含全部中央件、URL 配置等
占用内存（通常 100MB-500MB）

每个线程：

处理单个哀求
共享历程的内存空间
每个哀求独占一个线程，直到哀求完成

3. 多历程部署架构

Django 常见的生产部署架构

┌── Django 进程 1 ── 线程池
│
Nginx ── 负载均衡 ── Gunicorn ── Django 进程 2 ── 线程池
│
└── Django 进程 3 ── 线程池

复制代码

4. Django 对异步的有限支持

Django 3.1+ 开始支持异步视图和中央件

async def async_view(request):
# 可以使用 asyncio 原生功能
await asyncio.sleep(1)
# 但 ORM 仍然是同步的，需要转换
user = await sync_to_async(User.objects.get)(id=1)
# 异步模板渲染
return await sync_to_async(render)(
request, 'template.html', {'user': user}
)

复制代码

关键限制：

ORM 利用本质上仍是同步的
需使用 sync_to_async 适配器转换
混淆同步/异步代码可能导致性能损失

2.FastAPI 异步模子

1. FastAPI 的哀求处理机制

FastAPI 基于 Starlette 框架，原生支持异步

@app.get("/users/{user_id}")
async def get_user(user_id: int):
# 1. 异步数据库查询
user = await db.fetch_one("SELECT * FROM users WHERE id = :id", {"id": user_id})
# 2. 异步 HTTP 请求
async with httpx.AsyncClient() as client:
stats_response = await client.get(f"https://api.example.com/stats/{user_id}")
# 3. 所有 I/O 操作都不会阻塞事件循环
return {"user": user, "stats": stats_response.json()}

复制代码

2. FastAPI 中的事件循环与协程

在 FastAPI 应用中：
一个事件循环：

管理全部活泼的协程
分配 CPU 时间给准备运行的协程
监控 I/O 利用的完成环境

每个哀求：

由一个协程处理
碰到 await 时暂停，让出控制权
I/O 完成后恢复实行

3. await 关键字的作用

await 是异步编程的核心机制：

暂停点：await 标记了协程可以暂停的位置
控制权转移：当实行到 await 时，控制权返回给事件循环
挂起与恢复：协程挂起等候利用完成，之后才恢复实行

async def handler():
# 这里执行同步代码
result = await async_operation()
# 在上面的 await 处，协程会暂停执行
# 事件循环可以去处理其他协程（函数）
# 当 async_operation 完成后，协程恢复执行
return result

复制代码

4. 为什么 FastAPI 必须使用 await

在 FastAPI 中，await 是必须的，因为：

语法要求：Python 要求在异步函数中调用其他异步函数时必须使用 await
协作式多任务：没有 await，协程不会暂停，导致事件循环阻塞
资源管理：await 确保资源（如数据库毗连）正确开释

不使用 await 的后果

@app.get("/wrong")
async def wrong_way():
# 没有 await，返回协程对象而非结果
result = db.fetch_one("SELECT * FROM users") # 错误！
return result # 会返回一个未完成的协程对象
@app.get("/correct")
async def correct_way():
# 正确使用 await
result = await db.fetch_one("SELECT * FROM users")
return result # 返回实际查询结果

复制代码

十七、Django 与 FastAPI 的并发处理具体对比

1. Django 的并发模子（历程+线程）

# 单个请求处理流程
─────────────────────────────────────────────────────────────────────
│ │
│ Worker 进程 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 线程 (处理单个请求) │ │
│ │ ┌────────────────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ 1. 接收请求 │ │ │
│ │ │ 2. 中间件处理 │ │ │
│ │ │ 3. URL 解析 │ │ │
│ │ │ 4. 视图函数 │ │ │
│ │ │ │ │ │ │
│ │ │ ├─ 数据库查询 (阻塞) │ │ │
│ │ │ │ │ │ │
│ │ │ ├─ 外部 API 调用 (阻塞) │ │ │
│ │ │ │ │ │ │
│ │ │ └─ 模板渲染 │ │ │
│ │ │ │ │ │
│ │ │ 5. 响应生成 │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
─────────────────────────────────────────────────────────────────────

复制代码

特点分析

每个哀求独占一个线程
I/O 利用会阻塞整个线程
大量并发哀求必要大量线程
线程上下文切换开销大
内存占用高

2. FastAPI 的并发模子（事件循环+协程）

# 多个请求同时处理流程
─────────────────────────────────────────────────────────────────────
│ │
│ 单个 Worker 进程 │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 事件循环 │ │
│ │ ┌────────────────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ 协程 A (请求 1) │ │ │
│ │ │ ├─ 接收请求 │ │ │
│ │ │ ├─ 路径解析 │ │ │
│ │ │ ├─ 数据库查询 ──┐ │ │ │
│ │ │ │ (挂起，等待 I/O) │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ │ 协程 B (请求 2) │ │ │
│ │ │ │ │ ├─ 接收请求 │ │ │
│ │ │ │ │ ├─ 路径解析 │ │ │
│ │ │ │ │ ├─ API 调用 ───┐ │ │ │
│ │ │ │ │ │ (挂起，等待 I/O) │ │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ 协程 C... │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ │ ◄────────────┘ │ ◄────────────┘ │ │ │
│ │ │ │ (I/O 完成，恢复) │ (I/O 完成，恢复) │ │ │
│ │ │ │ │ │ │ │
│ │ │ ├─ 处理结果 ├─ 处理结果 │ │ │
│ │ │ └─ 返回响应 └─ 返回响应 │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
─────────────────────────────────────────────────────────────────────

复制代码

特点分析

单个历程处理多个并发哀求
I/O 利用不会阻塞事件循环
协程切换开销小
内存占用低
适当 I/O 密集型应用

十八、Django 与 FastAPI 服务器启动与历程配置详解

1. Django 的服务器启动与历程配置

1. Django 开发服务器（开发环境）

# 单进程、单线程模式
python manage.py runserver
# 指定 IP 和端口
python manage.py runserver 0.0.0.0:8000

复制代码

特点

单历程、单线程
不适当生产环境
自动代码重载

2. Django + Gunicorn 生产配置

# 基本启动
gunicorn myproject.wsgi:application
# 多进程配置（4个工作进程）
gunicorn myproject.wsgi:application --workers=4
# 多线程配置（每个进程2个线程）
gunicorn myproject.wsgi:application --workers=4 --threads=2
# 自动工作进程数（CPU核心数 x 2 + 1）
gunicorn myproject.wsgi:application --workers=$(( 2 * $(nproc) + 1 ))

复制代码

历程数目盘算

常见公式：(2 × CPU核心数) + 1
基于内存限制的盘算：可用内存 ÷ 每个历程内存占用

3. Django + uWSGI 生产配置

# uwsgi.ini 配置文件
[uwsgi]
module = myproject.wsgi:application
master = true
processes = 4
threads = 2
socket = /tmp/myproject.sock

复制代码

# 启动命令
uwsgi --ini uwsgi.ini

复制代码

FastAPI 的服务器启动与历程配置

1. Uvicorn 开发服务器（开发环境）

# 基本启动（单进程）
uvicorn main:app --reload
# 指定 IP 和端口
uvicorn main:app --host 0.0.0.0 --port 8000

复制代码

特点

单历程、单事件循环
支持代码热重载
适当开发环境

2. Uvicorn 生产配置

# 不使用热重载
uvicorn main:app --host 0.0.0.0 --port 8000
# 多进程模式需要 Gunicorn
gunicorn -w 4 -k uvicorn.workers.UvicornWorker main:app

复制代码

多历程异步配置

每个历程运行一个 Uvicorn 实例
每个 Uvicorn 实例有一个事件循环
历程间不共享内存，相互独立

3. 使用 Uvicorn 内置的多历程支持（仅实用于 Unix）

# 使用 Uvicorn 的工作进程
uvicorn main:app --workers 4

复制代码

十九、Django 与 FastAPI 内存和 CPU 利用对比

1. 内存使用

Django (同步模子)

每个历程：~200-500MB 基础内存
每个线程：~2-10MB 额外内存
总内存：历程数 × (基础内存 + 线程数 × 每线程内存)

比方，4个历程，每个2个线程：4 × (400MB + 2 × 5MB) = 1,640MB

FastAPI (异步模子)

每个历程：~150-300MB 基础内存
每个协程：~几KB 额外内存
总内存：历程数 × 基础内存 + 活泼协程数 × 每协程内存

比方，2个历程，1000个并发哀求：2 × 250MB + 1000 × 2KB = 502MB

2. CPU 利用率

Django (同步模子)

I/O 利用时，线程闲置但仍占用资源
大量闲置线程导致上下文切换开销
CPU 利用率通常不均衡：大量等候，少量盘算

FastAPI (异步模子)

I/O 利用时开释 CPU 资源给其他协程
协程切换开销小
CPU 利用率更均衡：更少的闲置时间

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。