asyncio.gather()默认采用fail-fast策略，任一协程抛出未捕获异常即中断执行并取消其余任务；设return_exceptions=True可将异常转为返回值，实现异常隔离；任务完全独立应改用create_task()+wait/as_completed。
asyncio.gather() 默认会取消所有未完成任务
当 asyncio.gather() 中某个协程抛出未捕获异常时，它**不会静默忽略**，而是立即中断执行，并尝试取消其他仍在运行的任务。这是它的默认行为——即“fail-fast”，不是“fire-and-forget”。
常见错误现象：RuntimeError: Task was destroyed but it is pending! 或者看到部分任务日志没打完就退出，说明它们被强制取消了。
- 除非显式传入
return_exceptions=True，否则只要有一个任务失败，整个gather()就 raise 异常，且其余任务会被 cancel - 被 cancel 的任务如果没处理
asyncio.CancelledError，可能留下资源泄漏（比如未关闭的连接、未 flush 的文件） - 即使任务已开始执行，只要还没返回，就可能被中断——不保证原子性
如何让其他任务不受单个异常影响？
用 return_exceptions=True 参数，这样异常会被包装成 Exception 实例，和其他正常返回值一起放进结果列表里，后续逻辑可以自行判断和处理。
import asyncioasync def task_a(): await asyncio.sleep(1) raise ValueError("oops in A")
async def task_b(): await asyncio.sleep(2) return "done B"
这样写，task_b 会继续跑完
results = await asyncio.gather( task_a(), task_b(), return_exceptions=True )
results == [ValueError('oops in A'), 'done B']
立即学习“Python免费学习笔记（深入）”；
- 结果列表中对应位置是异常对象，不是抛出异常；你得用
isinstance(r, Exception)判断 -
return_exceptions=True不影响任务调度本身，只是改变异常传播方式 - 注意：这不等于“重试”或“忽略”，只是把异常转为返回值，责任移交给你来处理
想彻底隔离任务，不共用生命周期怎么办？
如果任务之间本就不该互相干扰（比如一个监控任务 + 一个数据上报任务），gather() 本身就不是合适工具。应该改用 asyncio.create_task() 手动管理。
- 每个任务独立启动：
task_a = asyncio.create_task(task_a())，然后用asyncio.wait()或asyncio.as_completed()观察完成状态 -
asyncio.wait()支持return_when=asyncio.FIRST_EXCEPTION或ALL_COMPLETED，控制等待粒度 - 记得在 finally 块或 shutdown 阶段显式
await task.cancel()并await task等待清理，避免 warning
容易被忽略的细节：异常类型和 cancel 的先后顺序
如果多个任务几乎同时出错，gather() 只会抛出**第一个被检测到的异常**，其余异常会被丢弃（除非用了 return_exceptions=True）。而 cancel 操作本身也可能触发新的异常（如 CancelledError），但它通常不会向上冒泡——除非你在任务里主动 raise 它。
- 不要依赖“哪个异常先抛出来”，它受事件循环调度、await 点、I/O 延迟等影响，不可预测
- cancel 后任务若还在做 CPU 密集型工作，可能无法及时响应；建议在长循环中定期加
await asyncio.sleep(0)让出控制权 - 使用
asyncio.shield()可防止某个关键任务被gather()的 cancel 波及，但要小心死锁
