Django 4.x异步视图仅在ASGI服务器、无同步中间件、避免同步ORM时才能提升吞吐量；否则仍被线程阻塞，实际无效。
直接上结论：Django 4.x 的异步视图在 I/O 密集型场景（如调用外部 API、读写 Redis、长轮询）中确实能显著提升吞吐量，但前提是——你不用同步 ORM、不混用同步中间件、且部署在 ASGI 服务器上。否则，它只是“看起来异步”，实际仍被线程卡住。
async def 视图函数必须搭配 ASGI 服务器才能生效
Django 会自动识别 async def 视图，但 WSGI 模式下它只是在单次请求的独立事件循环里跑，无法复用底层异步能力。真正释放性能需要 uvicorn 或 daphne 这类 ASGI 服务器。
- 启动命令必须是
uvicorn myproject.asgi:application，不是python manage.py runserver -
manage.py runserver默认是 WSGI 模式，即使视图是async def，Django 也会退化为线程模拟，吞吐量无提升 - 检查是否真走 ASGI：访问接口时看日志里有没有
"Asynchronous handler adapted for middleware"—— 出现这句说明有同步中间件正在拖后腿
同步 ORM 必须用 sync_to_async() 包裹，不能直接 await
Django 的 ORM（包括 Model.objects.get()、.save()、.filter()）全是同步阻塞调用。在异步视图里直接调用会触发 Django 的异步安全保护，抛出 SynchronousOnlyOperation 错误。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 正确写法：
await sync_to_async(User.objects.get)(id=123)或更推荐带thread_sensitive=True：await sync_to_async(User.objects.get, thread_sensitive=True)(id=123) - 批量操作慎用：
sync_to_async本质是把同步调用扔进线程池，频繁调用反而增加调度开销；高并发下建议改用原生异步数据库驱动（如 asyncpg + django-postgres-extra），而非硬套 ORM - 注意：
select_related和prefetch_related在sync_to_async内部仍有效，但它们本身不解决异步问题，只是减少查询次数
混合中间件是吞吐量杀手，必须逐个排查
只要有一个同步中间件（比如 django.contrib.sessions.middleware.SessionMiddleware、django.middleware.csrf.CsrfViewMiddleware），Django 就必须为每个请求分配一个线程来保证上下文隔离 —— 异步视图的并发优势瞬间归零。
立即学习“Python免费学习笔记（深入）”；
- 默认中间件列表里，
SessionMiddleware和CsrfViewMiddleware是同步的；CommonMiddleware、SecurityMiddleware等支持 async/sync 双模式 - 临时验证方法：注释掉所有中间件，只留
django.middleware.common.CommonMiddleware，再压测；若 QPS 明显上升，说明其他中间件是瓶颈 - 生产环境无法移除 session？可考虑用异步友好的后端，比如
django-redis配合aioredis（需自行 patch 或等社区适配），或改用 JWT 无状态认证绕过 session 中间件
最常被忽略的一点：异步视图的性能收益几乎完全取决于「外部 I/O 占比」。如果接口 90% 时间花在 ORM 查询上，那优化方向应该是索引、缓存、读写分离，而不是强行改成 async def —— 同步 ORM 加 sync_to_async 只会让延迟更不可控。
