不会报错，前提是视图为async def且运行在ASGI环境下；否则会因上下文不匹配触发RuntimeError或SynchronousOnlyOperation异常。
async def view里直接await Model.objects.aget()会报错吗？
会，但只在你没用 async def 视图、或没配好 ASGI 服务器时才报。Django 5 的原生异步 ORM（如 aget()、aall()、acount()）要求调用栈全程异步：视图必须是 async def，且运行在 ASGI 模式（daphne、uvicorn 或 hypercorn），不能走 WSGI（runserver 默认是 WSGI，不支持 async ORM 调用）。
常见错误现象：SynchronousOnlyOperation: You cannot call this from an async context —— 这说明你混用了同步 ORM 方法（比如 .get()）在 async 视图里，或者反过来了；RuntimeError: This method must be run in async mode —— 表明你调了 .aget()，但当前线程/协程没被 Django 标记为 async 上下文（通常是 WSGI 启动导致）。
- 确认启动命令是
uvicorn myproject.asgi:application，不是python manage.py runserver - 检查
asgi.py是否被正确引用，且ASGI_APPLICATION = "myproject.asgi.application"在settings.py中已设置 - 所有调用异步 ORM 的函数必须用
async def定义，包括视图、辅助函数、管理命令的handle_async方法
Django 5 的 async ORM 支持哪些 QuerySet 方法？
不是所有方法都有异步版本。Django 5 提供的原生异步方法有限，集中在“终端操作”上，不支持链式异步过滤（比如 Book.objects.filter(...).aselect_related(...).afirst() 是非法的 —— filter() 本身仍是同步的，只返回普通 QuerySet）。
可用的异步方法只有这些（带 a 前缀）：aget()、afirst()、alast()、acount()、aexists()、aiterator()、aupdate()、adelete()。注意：aupdate() 和 adelete() 是对整个 QuerySet 执行的，不支持 save() 的异步版本（模型实例的 asave() 在 Django 5.0 中尚未实现，要等 5.1+）。
立即学习“Python免费学习笔记（深入）”；
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
-
select_related()和prefetch_related()仍是同步方法，但它们的异步等价物是aselect_related()和aprefetch_related()—— 这两个是 Django 5.0 新增的，仅限于外键/一对多预取，且必须在调用终端方法前链式使用 -
values()/values_list()没有异步版，想异步获取字典列表得先aiterator()再手动转 -
order_by()、filter()、exclude()等“惰性方法”全部保持同步，只是构建 QuerySet，不触发查询
如何安全地混合同步和异步数据库操作？
不能直接在同一个 async 函数里穿插 .get() 和 .aget()。Django 的数据库连接池（基于 aiomysql / asyncpg / aiosqlite）和同步连接池（pymysql / psycopg2）完全隔离。混用会导致连接复用失败或死锁。
真正安全的做法只有两种：全链路异步，或显式切换上下文。如果你必须在 async view 里调某个遗留的同步工具函数（比如一个封装了 .raw() 的统计函数），得用 sync_to_async 包装：
from asgiref.sync import sync_to_async
<p>@sync_to_async
def legacy_sync_db_call():
return Book.objects.raw("SELECT * FROM myapp_book LIMIT 1")[0]</p><h1>在 async view 中：</h1><p>book = await legacy_sync_db_call()但要注意：sync_to_async 本质是把同步调用扔进线程池，有额外开销；高频调用会抵消异步收益。更推荐的方式是逐步将同步逻辑重写为异步原生调用，或拆出独立同步服务进程（如 Celery worker）处理重 IO 任务。
- 不要用
asyncio.to_thread()替代sync_to_async—— 后者做了 Django 上下文（如数据库连接、信号）的自动传递 - 事务（
transaction.atomic()）目前不支持异步上下文，所有aupdate()/adelete()都是自动提交的，无法回滚；需要事务请退回同步视图 - SQLite 的异步驱动（
aiosqlite）在高并发下表现不稳定，生产环境建议用 PostgreSQL +asyncpg
为什么 await Book.objects.filter(...).afirst() 会报 AttributeError？
因为 filter() 返回的是普通 QuerySet，它没有 afirst() 方法 —— 异步方法只挂在 QuerySet 的“异步查询集”子类上，而 filter() 不会自动升级类型。你得先用 Book.objects.all().filter(...).afirst()，或者更规范地写成：
qs = Book.objects.filter(title__icontains="django") book = await qs.afirst() # ✅ 正确：QuerySet 实例确实有 afirst()
但注意：这行代码实际执行的是同步 filter + 异步 fetch，中间的 SQL 构建仍是同步的，只是最终查询由异步驱动发出。真正的“纯异步 ORM”指整个链路（构建 + 执行）都异步化，Django 目前只做到后者。
-
Book.objects.filter(...).aget()是合法的，因为aget()是 QuerySet 的方法，不限定是否经过 filter -
Book.objects.select_related("author").afirst()也合法，但select_related()本身同步，只是为后续afirst()预载关联数据 - 最易忽略的一点：模型字段的
db_column、choices等元信息读取仍是同步的，ORM 的“元层”未异步化
