Django ≥ 3.1 才原生支持 ASGI,需正确配置 asgi.py、ASGI_APPLICATION 设置及 Uvicorn Worker 依赖(如 uvicorn[standard]),否则无法启用异步能力;默认视图仍同步,仅 async 视图、WebSocket 和流式响应可获异步收益。

能用,但不是“让 Django 变成异步框架”,而是让 Django 的 ASGI 接口跑在 Uvicorn Worker 上——前提是 Django ≥ 3.1,且你明确启用了 ASGI 入口。
确认 Django 是否支持 ASGI 并正确暴露 application
Django 从 3.1 开始内置 ASGI 支持,但默认 manage.py runserver 仍走 WSGI。要启用异步能力,必须确保:
-
asgi.py文件存在且未被修改(Django 项目初始化时自动生成) -
settings.py中设置了ASGI_APPLICATION = 'myproject.asgi.application' -
asgi.py最终导出的是一个可调用对象,比如application = get_asgi_application(),而不是async def application(...)—— 后者是协程函数,不符合 ASGI 协议要求,Gunicorn 会报TypeError: 'coroutine' object is not callable - 如果你用了
channels(例如 WebSocket),需额外安装并注册,否则get_asgi_application()无法处理 async route
安装与 worker-class 必须匹配的依赖
只装 uvicorn 不够,Gunicorn 要识别 UvicornWorker 类,必须安装带 gunicorn 兼容层的版本:
pip install "uvicorn[standard]" gunicorn
立即学习“Python免费学习笔记(深入)”;
常见错误:
调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强,支持文件上传与图片 URL 输入。
- 装了
uvicorn但没加[standard]→ 启动时报ImportError: No module named 'uvicorn.workers' - 装了
gunicorn和uvicorn分开 →UvicornWorker类可能找不到或版本不兼容 - Python 环境混用(如 conda + pip 混装)→
gunicorn加载时找不到uvicorn.workers.UvicornWorker
启动命令中 -k 参数不能省,且端口由 Gunicorn 控制
Gunicorn 默认用同步 worker,必须显式指定 -k uvicorn.workers.UvicornWorker,否则请求会卡住或抛 RuntimeWarning: coroutine 'app' was never awaited。
典型命令:
gunicorn myproject.asgi:application -k uvicorn.workers.UvicornWorker -w 4 -b 0.0.0.0:8000 --reload
注意:
-
--host、--port是uvicorn命令行参数,在 Gunicorn 模式下无效;端口必须用-b指定 -
--reload仅用于开发,生产环境应禁用(改用--preload配合进程管理器如 systemd) -
-w数量建议设为(2 × CPU核心数) + 1,过多 worker 反而因上下文切换降低性能
别指望 Django 视图自动变 async,异步收益有明确边界
即使跑在 Uvicorn Worker 上,Django 默认视图仍是同步的。真正获得异步红利的场景只有:
- 使用
async def定义的视图(Django ≥ 3.1),且内部调用的是真正异步操作(如httpx.AsyncClient、aioredis、asyncpg) - WebSocket 连接(通过
channels) - 长轮询或流式响应(
StreamingHttpResponse配合 async generator)
如果只是把 ORM 查询(Model.objects.get())包进 async def,反而因同步阻塞导致 event loop 饥饿,性能更差。Django ORM 本身不是异步的,这点容易被忽略。


















