行，我给你压缩到一半长度，保留结论 + 关键机制 + 实操建议，直接能发博客那种。
⚠️ asyncio + pytest 大坑：
asyncio.create_task()
在测试中“卡死不动”
结论先行带 asyncio.create_task() 的后台异步代码，不要用 pytest 测，直接写脚本跑。
这是我在真实项目里踩到的一个非常隐蔽的坑，结论非常明确：
代码没问题，问题在测试框架。
问题现象
在 pytest 里测试一个异步 TokenKeeper（后台轮询 DB）：
asyncio.create_task(self._refresh_loop()) 已执行
await asyncio.sleep(50) 明确让出执行权
后台 task 完全不执行
只有在 Ctrl+C 中断 pytest 时，后台 task 才突然开始跑
同样代码，独立脚本运行一切正常。
根本原因（一句话版）
pytest 接管了 event loop，但不保证后台 task 的调度。
在 pytest（pytest-asyncio / anyio）里：
event loop 是“测试框架控制的”
测试 coroutine 是主任务
create_task 创建的后台任务 不属于测试任务树
pytest 在某些情况下 不会主动调度这些 task
所以你看到的是：
task 创建了，但永远拿不到执行时间片
为什么
asyncio.sleep()
也没用？
这是个常见误区。
sleep() 只是让当前 coroutine让权，
不等于 pytest 会调度后台 task。
结果就是：
你 sleep 50 秒，后台 task 还是不跑。
一个明确的“踩雷信号”
如果你发现：
后台 task 只在 Ctrl+C 时才继续执行
或测试结束时突然打印一堆后台日志
可以直接下结论：
你在用 pytest 测“服务型异步代码”，方式是错的。
哪些 async 代码不该用 pytest 测
只要命中任意一条，就别用 pytest：
asyncio.create_task
无限循环 / poll / keep-alive
后台刷新、守护任务
依赖 event loop 生命周期的逻辑
这些是“服务”，不是“函数”。
正确做法（强烈建议）
✅ 用独立脚本测试
async def main():keeper = AsyncTokenKeeper(...)await keeper.start()token = await keeper.wait_ready()print("token ready:", token)await asyncio.sleep(60)asyncio.run(main())用：
python scripts/run_async_token_keeper.py一切正常，逻辑符合直觉。
实战总结（重点）
pytest ≠ asyncio 运行时
create_task ≠ 一定会执行
后台 async 服务 ≠ 单元测试对象
服务型代码要“跑起来看”，不是“断言看”
怀疑 asyncio 前，先怀疑测试框架
最后一句话
异步服务代码，别迷信测试框架。脚本才是最诚实的测试方式。
pytest 适合测函数，
不适合测“会一直跑的东西”。
—— 踩坑记录
这次的坑有点大，留个机会，供大家参考
