Django本身不处理并发，真正扛住高并发的是uWSGI/ASGI进程模型+NGINX反向代理+数据库连接池+异步ORM（Django 5.0+），非I/O密集型场景改异步收益有限。
直接说结论：Django 本身不是为高并发设计的，但用对配置、避开阻塞点、配合异步支持（Django 5.0+）和外部组件，能撑住中等规模并发（比如 1k–3k RPS）。真要硬扛万级长连接或毫秒级响应，得换 FastAPI/Starlette 或加消息队列分流。
为什么默认 Django REST Framework 并发不高
Django 的同步 WSGI 模式（如 runserver 或 gunicorn --worker-class sync）每个请求独占一个 worker 进程/线程，数据库查询、HTTP 调用、文件读写等 I/O 操作会阻塞整个 worker。哪怕只是查一次 PostgreSQL，也可能卡住几十毫秒 —— 这期间它啥也干不了。
常见症状包括：
- 压测时
gunicornworker CPU 很低但响应延迟飙升 -
ps aux | grep gunicorn看到大量 worker 处于S（sleep）状态 - 数据库连接池耗尽，报错
django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections
必须改的 4 个关键配置项
不改这些，光写 APIView 或 ModelViewSet 没用。
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
-
gunicorn启动必须用异步 worker 类：gunicorn --worker-class gevent --workers 4 --worker-connections 1000（gevent需pip install gevent） - Django 数据库连接池要显式控制：
DATABASES['default']['CONN_MAX_AGE'] = 0（禁用持久连接），再配pgbouncer或django-db-geventpool做连接复用 - 关闭
DEBUG=True—— 它会让 Django 记录每条 SQL，严重拖慢响应；生产环境必须设为False - 静态资源交给 Nginx，别让 Django 处理
/static/或/media/，否则每个图片请求都进 Python
序列化器和视图里的性能雷区
ModelSerializer 默认会把关联字段全查出来（select_related/prefetch_related 不自动生效），一个接口可能触发十几轮 SQL 查询。
- 用
select_related('author')替代author.name这类外键访问，避免 N+1 - 列表接口强制加
pagination_class，别让前端传?limit=10000就真查一万条 - 避免在
to_representation()里做数据库查询或 HTTP 请求 —— 这是常见反模式 - 如果字段计算开销大（比如拼接多个 JSON 字段），考虑用数据库
Func或annotate()提前算好
Django 5.0+ 异步支持怎么用才有效
异步视图只在 I/O 密集场景有用（比如调第三方 API、缓存读写），对纯数据库操作提升有限 —— 因为 async def 视图里调 await Model.objects.async_all() 才真正异步，而 DRF 默认还是走同步 ORM。
- 先确保数据库驱动支持异步：
pip install asyncpg（PostgreSQL）或aiomysql（MySQL） - 视图函数声明为
async def list(self, request)，但序列化器仍需保持同步（DRF 3.15 尚未原生支持 async serializer） - 缓存推荐用
aioredis+cache_page装饰器，比同步redis-py快 3–5 倍 - 别把所有视图都改成 async —— 同步代码混 async 反而更慢，Python 的 async/await 切换有开销
最常被忽略的一点：高并发下瓶颈往往不在 Python 层，而在数据库连接数、Nginx worker_connections、系统 ulimit -n 限制。上线前务必用 ab 或 wrk 实测，而不是只看本地 runserver 的 QPS。
