背景概述

在Python的异步编程生态中，asyncio和 anyio都提供了TaskGroup功能来管理并发任务。虽然它们在API设计上相似，但在具体的行为实现上存在一些微妙且重要的差异。本文通过实际代码测试和深度分析，揭示这些差异的本质。

测试代码分析

测试环境

我们使用以下两个测试文件来观察行为差异：

asyncio版本测试:

import asyncio

async def cancel_soon():
    print("cancel_soon starting")
    await asyncio.sleep(0.5)
    raise RuntimeError

async def wait_and_print(i):
    print(f"Wait {i} starting")
    try:
        await asyncio.sleep(1)
        print(f"Wait {i} done")
    except BaseException as e:
        print(f"Wait {i} except: {e!r}")
        raise

async def double_wait():
    try:
        await wait_and_print(1)
    finally:
        await wait_and_print(2)

async def asyncio_group_test():
    try:
        async with asyncio.TaskGroup() as tg:
            tg.create_task(double_wait())
            tg.create_task(cancel_soon())
    except Exception as e:
        print(f"test caught: {e!r}")

asyncio.run(asyncio_group_test())

anyio版本测试:

import anyio

async def cancel_soon():
    print("cancel_soon starting")
    await anyio.sleep(0.5)
    raise RuntimeError

async def wait_and_print(i):
    print(f"Wait {i} starting")
    try:
        await anyio.sleep(1)
        print(f"Wait {i} done")
    except BaseException as e:
        print(f"Wait {i} except: {e!r}")
        raise

async def double_wait():
    try:
        await wait_and_print(1)
    finally:
        await wait_and_print(2)

async def anyio_group_test():
    try:
        async with anyio.create_task_group() as tg:
            tg.start_soon(double_wait)
            tg.start_soon(cancel_soon)
    except Exception as e:
        print(f"test caught: {e!r}")

anyio.run(anyio_group_test)

实际运行结果对比

asyncio.TaskGroup的行为

Wait 1 starting
cancel_soon starting
Wait 1 except: CancelledError()
Wait 2 starting
Wait 2 done
test caught: ExceptionGroup('unhandled errors in a TaskGroup', [RuntimeError()])

anyio.create_task_group的行为

Wait 1 starting
cancel_soon starting
Wait 1 except: CancelledError('Cancelled by cancel scope 10c096900')
Wait 2 starting
Wait 2 except: CancelledError('Cancelled by cancel scope 10c096900')
test caught: ExceptionGroup('unhandled errors in a TaskGroup', [RuntimeError()])

关键差异分析

1. finally块的取消行为

这是两者最显著的差异：

asyncio.TaskGroup:

当 cancel_soon任务抛出异常时，会取消其他任务
double_wait函数中的 finally块会继续执行
wait_and_print(2)在finally块中完整执行完成，输出"Wait 2 done"

anyio.create_task_group:

同样会取消其他任务
但是 finally块中的 wait_and_print(2)也会被取消
输出"Wait 2 except: CancelledError(...)"

2. 取消传播的彻底性

asyncio的取消语义

# asyncio允许finally块中的异步操作完成
try:
    await wait_and_print(1)  # 被取消
finally:
    await wait_and_print(2)  # 继续执行完成

anyio的取消语义

# anyio的取消会传播到所有嵌套的异步操作
try:
    await wait_and_print(1)  # 被取消
finally:
    await wait_and_print(2)  # 也被取消

3. 取消作用域(Cancel Scope)的概念差异

anyio的设计哲学:

基于Trio的"结构化并发"理念
使用显式的取消作用域(Cancel Scope)
取消信号会递归传播到所有子操作
错误消息中包含具体的取消作用域ID：'Cancelled by cancel scope 10c096900'

asyncio的设计哲学:

取消更加"温和"，允许清理操作完成
finally块被视为清理代码，应该有机会完成
错误消息更简洁：CancelledError()

设计理念的深层差异

Trio/AnyIO的结构化并发

AnyIO遵循Trio的结构化并发原则：

严格的生命周期管理: 所有子任务必须在父作用域结束前完成或被取消
递归取消: 取消信号会传播到所有嵌套层级
明确的边界: 使用Cancel Scope明确定义取消边界

# anyio中的取消是"全有或全无"
async with anyio.create_task_group() as tg:
    # 任何异常都会导致整个组被取消
    # 包括finally块中的操作

AsyncIO的实用主义方法

AsyncIO采用更加实用的方法：

清理友好: 允许finally块完成必要的清理工作
渐进式取消: 不会阻断所有的清理操作
向后兼容: 保持与传统asyncio代码的兼容性

# asyncio允许清理代码完成
async with asyncio.TaskGroup() as tg:
    # 异常发生时，finally块仍有机会完成

实际应用场景的影响

1. 资源清理场景

使用asyncio时:

async def with_resource():
    try:
        await some_operation()
    finally:
        await cleanup_resource()  # 会完成执行

使用anyio时:

async def with_resource():
    try:
        await some_operation()
    finally:
        # 可能被取消，需要使用CancelScope屏蔽
        with anyio.CancelScope(shield=True):
            await cleanup_resource()

2. 错误处理策略

由于anyio的取消更加彻底，在编写错误处理代码时需要考虑：

# anyio中需要显式保护关键清理代码
async def critical_operation():
    try:
        await main_work()
    except Exception:
        with anyio.CancelScope(shield=True):
            await emergency_cleanup()
    finally:
        with anyio.CancelScope(shield=True):
            await final_cleanup()

性能和可靠性考量

AnyIO的优势

更强的一致性: 取消行为完全可预测
更好的资源管理: 避免资源泄露
清晰的错误边界: 异常处理更加明确

AsyncIO的优势

更灵活的清理: 允许重要的清理操作完成
更好的兼容性: 与现有代码库集成更容易
更少的样板代码: 不需要显式的屏蔽取消

选择建议

选择AnyIO的场景

新项目: 从零开始设计的系统
严格的资源管理: 需要精确控制任务生命周期
复杂的并发逻辑: 需要结构化并发的清晰性
跨平台兼容: 需要同时支持asyncio和trio

选择AsyncIO的场景

现有项目迁移: 已有大量asyncio代码
清理操作复杂: 需要在finally块中执行复杂清理
标准库优先: 希望减少第三方依赖
Python 3.11+: 可以充分利用新的异常组特性

结论

asyncio.TaskGroup和 anyio.create_task_group在API设计上相似，但在取消语义上存在本质差异。AnyIO提供了更严格、更一致的结构化并发模型，而AsyncIO则在严格性和实用性之间找到了平衡。

选择哪个框架应该基于具体的项目需求：如果你需要严格的生命周期管理和可预测的取消行为，AnyIO是更好的选择；如果你需要更灵活的清理机制和更好的向后兼容性，AsyncIO可能更适合。

理解这些差异对于编写健壮的异步代码至关重要，特别是在处理错误恢复和资源清理时。无论选择哪个框架，都应该根据其特定的语义来设计异常处理和资源管理策略。

目录CONTENT

【Python】asyncio与anyio的TaskGroup行为差异深度解析