回调函数绑定给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()（后者不绑定事件循环）
