Python Django 5.0中对异步装饰器的支持有哪些新改进？-Python教程-PHP中文网

django 5.0 允许 async def 视图函数被 asgi 服务器原生执行，自动调度同步 orm 调用至线程池，无需手动 wrap sync_to_async；支持类视图方法级异步、加固 sync_to_async/async_to_sync、装饰器兼容但不参与异步生命周期。

python django 5.0中对异步装饰器的支持有哪些新改进？

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。

Shadows Python Sensei

Python 最佳实践助手——代码规范、设计模式、性能优化、测试与类型注解。适用于编写或审查 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 查询，直接导致事件循环卡死

实际项目里最容易被忽略的点是：**异步视图的性能收益完全取决于 I/O 占比**。如果一个视图 90% 时间花在模板渲染或 Python 循环上，改成 async def 不但没提速，还增加调度开销。真要压榨性能，得配合异步 ORM（afirst()、aupdate()）和异步数据库驱动（如 aiopg 或 asyncpg），而不是只改函数声明。