Django 5.0 允许 async def 视图函数被 ASGI 服务器原生执行，自动调度同步 ORM 调用至线程池，无需手动 wrap sync_to_async；支持类视图方法级异步、加固 sync_to_async/async_to_sync、装饰器兼容但不参与异步生命周期。
async def 视图函数不再需要手动套 sync_to_async
Django 5.0 的核心改进是让 async def 视图函数能被 ASGI 服务器原生识别和执行，框架自动处理协程调度。此前（4.x 及更早）即使写了 async def，若内部调用同步 ORM 方法（如 MyModel.objects.get()），仍必须显式包裹 sync_to_async(MyModel.objects.get)(id=1)，否则会阻塞事件循环。
现在只要视图本身是 async def，Django 就默认启用异步上下文，无需再为每个同步调用加适配器——但注意：这只是“自动调度”，不是“自动异步化”。底层仍是同步操作，只是被安全地交由线程池执行，不卡住主事件循环。
- 适用场景：快速迁移旧视图，保留同步 ORM 逻辑的同时获得并发收益
- 性能影响：仍存在线程切换开销，吞吐提升有限（实测约 2–3 倍），远低于全链路异步
- 容易踩的坑：误以为
MyModel.objects.filter().first()变成了异步——它没变，只是被框架悄悄扔进线程池跑
sync_to_async 和 async_to_sync 的行为更可靠
5.0 对这两个适配器做了关键加固：支持嵌套调用、正确传递上下文（如数据库连接、请求对象）、避免在多层 await 中丢失事务状态。以前在复杂中间件或信号中混用时，常出现 RuntimeError: There is no current event loop in thread 或连接复用错误。
现在它们会主动检测当前是否处于 ASGI 环境，并选择合适的执行策略（线程池 or event loop），而不是盲目 fallback。
立即学习“Python免费学习笔记（深入）”；
- 典型用法：在异步视图里调用传统同步工具函数（如第三方 SDK、自定义校验逻辑）
- 参数差异：
sync_to_async(func, thread_sensitive=True)默认值已改为True，防止 ORM 连接跨线程泄漏 - 容易踩的坑：把
thread_sensitive=False用于 Django ORM 操作——会导致连接复用异常或数据污染
类视图方法级异步支持更细粒度
5.0 允许只对类视图中的特定 HTTP 方法（如 get 或 post）声明为 async def，其余方法保持同步。这比整个 dispatch 异步更实用，尤其适合混合场景：比如 get 查缓存（可异步），post 写数据库（暂用同步 ORM）。
框架会按方法签名自动路由，不需要重写 dispatch 或手动判断 is_coroutine_function。
- 使用示例：
async def get(self, request, *args, **kwargs):+def post(self, request, *args, **kwargs): - 兼容性注意：如果父类方法是同步的，子类覆盖为异步，Django 会正确继承并执行；反之则报
TypeError - 容易踩的坑：在异步
get中直接调用同步self.form.is_valid()——表单验证仍是同步的，但无需额外包装，框架已内置适配
装饰器本身没新增，但用法边界更清晰
Django 5.0 并未引入新装饰器（如 @async_view），也未修改 @login_required 等现有装饰器的行为。所有装饰器仍按同步方式工作；若套在 async def 视图上，Django 会尝试将其转为协程兼容形式——但仅限于简单装饰器（无状态、无副作用）。
真正关键的是：你不能再依赖装饰器内部做 I/O（如装饰器里调 API），因为装饰器执行发生在视图函数调用前，且不参与异步生命周期管理。
- 推荐做法：把需异步的逻辑移到视图函数体内，用
await显式控制 - 常见错误现象：
TypeError: object ... can't be used in 'await' expression—— 本质是装饰器返回了普通 callable，而非协程 - 容易踩的坑：给异步视图叠加多个自定义装饰器，其中某个用了
time.sleep()或同步 DB 查询，直接导致事件循环卡死
async def 不但没提速，还增加调度开销。真要压榨性能，得配合异步 ORM（afirst()、aupdate()）和异步数据库驱动（如 aiopg 或 asyncpg），而不是只改函数声明。 
