Python异步回调与Future对象详解

回调函数绑定给Future或Task对象而非async def函数，触发于其done状态变化；须用create_task等显式获取任务对象才能绑定，且回调中需检查exception()再调用result()。

asyncio里回调函数到底绑给谁？

不是绑给 async def 函数，而是绑给它返回的 Future 或 Task 对象。你写 task.add_done_callback(cb)，回调触发时机是这个 task 状态变成 done（完成或取消），和 await 无关。

常见错误：在 await coro() 后直接加回调，结果根本不会执行——因为 await 解包的是结果，不是 Future；你拿到的是返回值，不是可绑定回调的对象。

• 正确做法：用 asyncio.create_task(coro()) 或 loop.create_future() 显式拿到 Task/Future 实例再绑
• 注意：asyncio.ensure_future() 在 Python 3.7+ 已不推荐，优先用 create_task()
• 回调函数签名必须是 def cb(fut: asyncio.Future) -> None，不能带额外参数（需用闭包或 functools.partial）

回调里怎么安全获取返回值或异常？

不能直接访问 fut.result() 而不检查状态，否则会抛 InvalidStateError。Future 在 done() 为 True 后才允许调用 result() 或 exception()。

典型场景：你想在任务结束后打印结果，但任务可能失败。

• 先用 fut.done() 判断（虽然回调触发时基本已是 done，但防御性编程建议仍检查）
• 用 fut.exception() 检查是否出错；若返回非 None，说明有未处理异常
• 只有 fut.exception() is None 时，才能安全调用 fut.result()
• 别在回调里 await 其他协程——回调运行在事件循环线程中，但不是协程上下文，会报 RuntimeError: await outside async function

def log_result(fut):
    if fut.exception():
        print("失败:", fut.exception())
    else:
        print("成功:", fut.result())

为什么 add_done_callback 不如 await + try/except 常用？

因为回调破坏了代码的线性控制流，调试困难、错误传播隐晦、无法自然处理中间状态（比如“正在运行中”）。asyncio 的设计哲学是：协程之间用 await 组合，调度由事件循环统一管理。

使用场景其实很窄：主要用于底层集成（比如把 callback-style 的库桥接到 asyncio）、或需要“fire-and-forget + 最终通知”的日志/清理逻辑。

• 性能上没优势：回调函数仍被事件循环调度，开销和 await 差不多
• 兼容性注意：某些异步框架（如 Trio）根本不支持 Future 回调机制，纯靠结构化并发
• 如果只是想“任务做完干点事”，95% 的情况应该写成 await task 后续操作，而不是绑回调

Future 和 Task 的回调行为差异

Task 是 Future 的子类，所以 add_done_callback 行为一致，但 Task 多一个关键特性：它知道自己的协程栈帧，出错时能提供更完整的 traceback。

容易踩的坑：直接对普通协程对象（coro）调用 add_done_callback 会报 AttributeError——协程对象没有这个方法，必须先包装成 Task。

• 判断类型：用 isinstance(obj, asyncio.Future)，不要用 type(obj).__name__
• asyncio.sleep(1) 返回的是协程对象，不是 Future；asyncio.create_task(asyncio.sleep(1)) 才返回 Task
• 手动创建 Future 时，记得用 loop.create_future()，而不是直接 asyncio.Future()（后者不绑定事件循环）

实际用的时候，最常被忽略的是回调函数的执行时机不可控：它可能在任意一次事件循环迭代中被调用，且和你主线程的 await 点完全解耦。这意味着共享状态要小心竞态，尤其涉及 logging、计数器、UI 更新这类操作。