Python 310 协程库失效原因解析 asyncio API 变更详解

如果你在Python 3.10或更高版本中运行旧代码时，遇到了诸如RuntimeWarning: coroutine 'xxx' was never awaited或TypeError: object xxx can't be used in 'await' expression这样的错误，先别急着怀疑人生。这通常不是什么玄学问题，而是代码里混用了新旧两种协程范式。从Python 3.10开始，asyncio模块对旧式协程的支持被彻底移除了，这不是简单的“失效”，而是一次正式的、彻底的切割。

简单来说，基于@asyncio.coroutine装饰器和yield from语法的生成器协程，在3.10里已经不再是合法的协程了。事件循环、await表达式以及asyncio.create_task()等核心机制，都将拒绝识别它们。

asyncio.coroutine 装饰器在 3.10 中已被完全移除

其实，自Python 3.5引入async/await语法起，旧式协程就已经进入了软弃用状态。而Python 3.10则是一个硬切割点，意味着所有兼容性后路都被堵死了：

• @asyncio.coroutine装饰器本身已从asyncio模块中删除。尝试导入或使用它会直接触发AttributeError: module 'asyncio' has no attribute 'coroutine'。
• 退一步讲，即使你通过某种方式保留了装饰器逻辑，底层的事件循环也不再会将生成器对象识别为合法的协程。无论是asyncio.run()、await表达式，还是create_task()，都会对generator类型说“不”。
• 从官方文档到测试用例，再到CPython的源码，所有相关的兼容性分支和覆盖路径都已被清理干净。这标志着旧时代的彻底终结。

如何快速识别代码里还藏着旧协程

排查起来并不复杂，重点盯着以下三种模式就行：

• 函数定义上还挂着@asyncio.coroutine装饰器（哪怕只是import语句里出现过）。
• 函数体内部还在使用yield from asyncio.sleep(...)或yield from some_coro()这样的调用。
• 调用链的某个环节返回的是types.GeneratorType对象，却被后续代码当作可等待对象传给了await或asyncio.create_task()。

这里有个简单的验证技巧，可以帮你快速判断：

import inspect

def old_style():
    yield from asyncio.sleep(1)

print(inspect.iscoroutinefunction(old_style))  # False
print(inspect.isgeneratorfunction(old_style))  # True

如果第二行输出是True，那这个函数就属于必须重写的旧协程范畴。

asyncio.Lock.acquire() 等方法不再接受 loop 参数

这个问题虽然不直接涉及协程语法，但常常被误认为是“API失效”，值得单独提一下。

• 在Python 3.10中，asyncio.Lock.__init__(loop=None)和acquire(loop=None)方法里的loop参数被移除了。
• 如果你的代码里还写着lock = asyncio.Lock(loop=loop)或await lock.acquire(loop=loop)，就会触发TypeError: __init__() got an unexpected keyword argument 'loop'。
• 正确的写法是直接lock = asyncio.Lock()。它会自动绑定到当前正在运行的事件循环（通过get_running_loop()获取）。
• 同样的规则也适用于asyncio.Event、asyncio.Semaphore等其他同步原语。

迁移时最容易忽略的兼容细节

真正让开发者头疼的，往往不是语法上的直接改写，而是那些隐性的依赖和行为差异：

• 类型差异：旧协程函数返回的是生成器对象，可能被一些早期框架（比如某个版本的aiohttp或自定义的中间件）当作可调度单元。而新协程返回的是coroutine对象，类型检查更为严格。
• API行为不一致：asyncio.ensure_future()在3.10中间出于向后兼容的考虑，仍然可以包装旧的生成器，但它返回的是一个Future对象，而不是Task，这可能导致行为不一致。最佳实践是统一改用asyncio.create_task()。
• 测试模拟的陷阱：在单元测试中，如果使用mock.AsyncMock来模拟旧协程，需要确保其side_effect返回的是真正的协程对象，而不是一个模拟的生成器。

话说回来，改完语法并不代表万事大吉。一个稳妥的建议是，在持续集成（CI）流程中强制开启-Werror::DeprecationWarning选项，这样就能提前暴露那些残留的、处于过渡期的API调用，把问题扼杀在萌芽状态。