Python 新异步任务组能力如何影响服务编排

如果把用户请求看成一次“编排”，真正值得关注的不是 Python 3.14 又多了一个并发 API，而是 asyncio.TaskGroup 把任务的创建、等待、失败传播和取消收进了同一个生命周期。需要先纠正一个容易混淆的说法：TaskGroup 从 Python 3.11 就存在；Python 3.13 主要改进取消冲突处理，Python 3.14 才进一步把任务创建参数向事件循环透传，并提供 eager_start 入口。升级收益因此集中在边界更清楚、框架扩展更顺手，而不是简单“并发更快”。

先把三个版本的变化拆开

服务编排常见的场景是：一次请求同时读取用户资料、额度和推荐结果，全部完成后再拼装响应。旧式的 create_task() 需要调用方自己保存任务引用、逐个等待并处理未取出的异常。TaskGroup 用异步上下文把这组任务包起来，离开 async with 时再统一等待。

因此，升级到 3.14 前先问清楚：你需要的是更可靠的取消语义，还是要把任务名称、上下文和调度参数交给框架。如果只是把 gather() 换成 TaskGroup，收益主要来自生命周期和异常模型。

为什么 TaskGroup 更适合请求内的服务编排

下面这个例子把三个下游调用放在同一组里。上下文退出后，三个任务都已经结束；如果其中一个抛出普通异常，TaskGroup 会取消仍在运行的兄弟任务，并把异常以异常组形式交给上层。这个行为比“后台任务继续跑，最后才发现请求已经失败”更容易控制资源和延迟。

import asyncio

async def assemble_home(user_id: str):
    # 同一请求内的相关下游调用共享一个生命周期
    async with asyncio.TaskGroup() as group:
        profile = group.create_task(load_profile(user_id), name="profile")
        quota = group.create_task(load_quota(user_id), name="quota")
        recommend = group.create_task(load_recommendations(user_id), name="recommendation")

    # 退出上下文后再读取结果，避免遗漏仍在运行的任务
    return {
        "profile": profile.result(),
        "quota": quota.result(),
        "recommendations": recommend.result(),
    }

async def endpoint(user_id: str):
    try:
        return await assemble_home(user_id)
    except* TimeoutError as errors:
        # 只把可识别的下游超时转换成接口层的降级结果
        return {"degraded": True, "reason": f"timeouts={len(errors.exceptions)}"}

图1是这段关系的操作示意图：重点不在某个框架的界面，而在“组内失败—兄弟取消—统一退出”的边界。要注意，CancelledError 不会按普通异常触发同样的失败传播；超时、主动取消和业务异常应分别设计返回策略。

升级到 Python 3.14 前要先确认哪些兼容边界

3.14 的 eager_start 不是“免费加速开关”。它可能让协程在创建任务的调用点就开始同步执行，执行顺序和异常出现时机都可能改变。只有当团队明确接受这种语义，并且已经为缓存命中、任务命名、上下文变量和自定义 task factory 做过回归，才适合在框架层打开它。

另一个边界是 kwargs 透传。若服务使用了自定义事件循环或任务工厂，3.14 的透传行为可能暴露出工厂签名不兼容。先在测试环境覆盖“组未进入、组正在退出、子任务同时失败、外部取消撞上内部失败”四类场景，再决定是否升级生产运行时。

上线前用这张清单判断是否值得采用

• 任务是否属于同一次请求或同一个明确的业务作用域？如果要跨进程重试，不要只靠 TaskGroup。
• 失败时是否应该取消兄弟任务？若某项允许独立完成，应拆成不同作用域或显式收集结果。
• 每个下游是否有超时、取消后的连接释放和可观测任务名？没有这些信息，结构化并发也很难排障。
• 升级后是否测试了自定义 task factory、contextvars、ExceptionGroup 和降级响应？

我的判断是：TaskGroup 的新变化更适合用来收紧服务内部的并发边界，而不是拿来替代完整的任务平台。先把一次请求内的相关任务归组，再把重试、持久化和跨机器调度交给更合适的基础设施，升级收益会更稳定。

相关问题

TaskGroup 和 asyncio.gather() 要怎么选？

需要结构化生命周期、失败时联动取消时优先 TaskGroup；只想收集多个 awaitable 的结果且已经有独立错误策略时，gather() 仍然可以使用。

Python 3.13 能直接使用 eager_start 吗？

不能把 3.14 的参数当成跨版本兼容 API。需要支持 3.13 时，应通过版本分支或保持默认调度，并为两条路径分别做行为测试。

TaskGroup 能保证跨服务事务一致吗？

不能。它只管理当前事件循环里的协程生命周期；跨服务一致性仍要依靠幂等、补偿、消息投递或工作流状态。