需检查运行时事件循环ID是否一致，并观察日志是否有“Synchronous middleware adapted”提示；若存在同步中间件或驱动不支持异步，Django会静默降级为线程模式。
怎么确认Django异步视图真的在跑 async 逻辑？
只看 async def get(self, request) 或 async def my_view(request) 不代表它真走异步路径——Django 会根据部署模式、中间件、甚至请求上下文动态降级。最直接的验证方式是检查运行时是否进入 asyncio 事件循环，而不是被塞进线程里执行。
关键判断点：在视图函数内部打印 asyncio.get_event_loop() 的 ID，再对比同一请求中其他地方（比如中间件或信号）的 loop ID 是否一致；如果不一致，说明被线程兜底了。
- 在 ASGI 模式下且无同步中间件时，loop ID 应该稳定不变
- 只要有一个同步中间件（如
SessionMiddleware默认就是），Django 就会为每个请求新建线程，并在其中启动一次性 event loop —— 此时你看到的 loop 是临时的，且和全局 loop 不同 - 用
logging.getLogger("django.request").setLevel(logging.DEBUG)并观察日志里有没有"Synchronous middleware adapted"这类提示，有就等于异步栈被截断
为什么 sync_to_async 调用后还是报错“SynchronousOnlyOperation”？
常见现象是：你在异步视图里写了 await sync_to_async(Blog.objects.get)(pk=1)，但依然触发 SynchronousOnlyOperation 异常。这不是 sync_to_async 失效，而是你调用的位置不对。
-
sync_to_async必须在真正异步上下文中调用，即：它得在async def函数体内，且该函数已被 Django 的 ASGI handler 正确识别为协程 - 如果视图本身被中间件强制转成同步执行（比如用了
CommonMiddleware+SecurityMiddleware组合且未适配），那整个函数体其实是在线程里以同步方式运行的，await语法虽不报错，但sync_to_async内部无法获取有效 loop，就会 fallback 到保护机制 - 别在
__init__、as_view()或类属性定义里调用sync_to_async—— 这些都不是请求处理阶段，没有 event loop 可用
如何用 pytest 验证异步视图是否响应正确？
不能靠 Client（WSGI 测试客户端），它根本不支持 await；必须用 AsyncClient，且测试函数本身得是 async def，还要确保 pytest 启用了 asyncio_mode = auto。
立即学习“Python免费学习笔记（深入）”；
- 安装依赖：
pip install pytest-asyncio - 配置
pyproject.toml：[tool.pytest.ini_options] asyncio_mode = "auto" - 测试写法必须是：
@pytest.mark.asyncio+async def test_my_async_view():+await client.get("/api/items/") - 如果漏掉
async def或没配asyncio_mode，测试会静默通过，但实际没发请求——因为AsyncClient.get()返回的是协程对象，不是响应 - 错误示例：
response = client.get(...)（没 await）→response是<coroutine object>，后续assert response.status_code == 200会报AttributeError
最容易被忽略的异步失效点：数据库连接池和缓存客户端
即使视图和 ORM 调用都走通了 async 路径，如果底层驱动不支持异步，Django 仍会 fallback 到线程模型。比如：
- 默认 SQLite、PostgreSQL（psycopg2）、MySQL（mysqlclient）都是同步驱动，
sync_to_async是唯一选择，但性能瓶颈仍在 - 要用真正异步驱动：PostgreSQL 推荐
asyncpg，MySQL 推荐aiomysql，Redis 推荐redis-py的from redis.asyncio import Redis - 注意连接池初始化时机：在模块顶层
redis_client = Redis(...)是危险的，因为不同测试用例的 event loop 不共享，容易导致连接泄漏或RuntimeError: Event loop is closed - 推荐做法：把 client 初始化放进 fixture，用
scope="function"+autouse=True，并在 teardown 里显式await client.aclose()
