asyncio.gather会静默丢弃异常并中断清理，而taskgroup强制async with、保障资源释放并聚合异常为exceptiongroup，需用except*捕获。
asyncio.gather 会静默丢弃异常，而 TaskGroup 不会
Python 3.10 及更早版本中，asyncio.gather() 遇到任一子任务抛出异常时，会立即取消其余任务，且不等待它们执行 finally 或退出 async with 块。这意味着数据库连接可能没关闭、临时文件没清理、锁没释放——你只看到第一个异常，其他资源泄漏完全无声。
Python 3.11 引入的 asyncio.TaskGroup 改变了这一行为：它强制用 async with TaskGroup() as tg: 包裹，所有子任务必须通过 tg.create_task() 启动。任一任务异常后，其他任务收到取消信号，但会继续运行至自然结束（比如完成 async with 的退出逻辑），再聚合异常为 ExceptionGroup。
- 旧写法：
results = await asyncio.gather(task1(), task2(), task3())—— 无法捕获多个异常，也无法保证清理 - 新写法：
async with asyncio.TaskGroup() as tg: tg.create_task(task1()); tg.create_task(task2())—— 必须用except*捕获，不能用普通except - 注意：
TaskGroup不保留结果顺序，别依赖[t1.result(), t2.result()]的索引对应关系
ExceptionGroup 和 except* 是 3.11 的硬性新增语法
在 Python 3.11 之前，多个并发异常只能靠手动收集或第三方库模拟；3.11 把 ExceptionGroup 写进语言规范，并配套引入 except* 语法来解包。这不是可选特性，而是 TaskGroup 异常传播的唯一合法出口。
如果你在 3.11+ 环境里仍用 except ValueError: 去捕获由 TaskGroup 抛出的异常，会直接漏掉——因为实际类型是 ExceptionGroup，里面嵌套着若干个 ValueError 实例。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 正确写法：
except* ValueError as eg:——eg.exceptions是原始异常列表 - 错误写法：
except ValueError:—— 完全匹配不上，异常向上冒泡 -
except* Exception:可兜底，但会掩盖具体类型，不利于精准处理
get_running_loop() 在 3.7+ 已可用，但 3.11 更严格限制 get_event_loop()
Python 3.7 引入 asyncio.get_running_loop() 替代模糊的 get_event_loop()，用于协程内部安全获取当前运行的 loop。这个 API 在 3.11 中仍是推荐做法，但 get_event_loop() 的行为变得更危险：
- 3.11+ 中，若当前线程无运行中的 loop，
get_event_loop()会发出DeprecationWarning - 3.12 起该调用将直接报错，不是警告
- 尤其在测试或 CLI 工具中，容易因未显式启动 loop 就调用
get_event_loop()导致静默失败
简单判断：只要你在协程里，就该无条件用 get_running_loop()；只有在主线程初始化阶段（比如 asyncio.run() 外）才可能需要 new_event_loop()，且必须配对 close()。
asyncio.run() 的 debug 参数在 3.11 下更敏感
asyncio.run(main(), debug=True) 在 3.11 中启用的调试检查比旧版本更激进：除了原有的未 await Task 警告、耗时回调提示外，还新增对“长时间阻塞同步调用”的探测（比如在协程里调用 time.sleep()）。这类问题在 3.10 可能仅表现为延迟，但在 3.11+ 的 debug 模式下会立刻打印 warning。
- 典型触发场景：
await asyncio.to_thread(os.listdir, "/slow/nfs/path")被误写成os.listdir() - debug 模式下，解释器会检测事件循环是否被同步 I/O 卡住超过阈值（默认 100ms）
- 这个检查在生产环境默认关闭，但 CI 流程中开启 debug 很容易暴露隐藏的同步阻塞点
真正麻烦的是：这些 warning 不中断执行，也不改变返回值，但会在日志里埋雷——等压测时才发现吞吐量卡在某个固定值上，根源却是某处忘了加 to_thread。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
