TaskGroup.create_task() 与 create_task() 的本质区别在于生命周期管理主体不同：前者由 TaskGroup 自动统一管理任务的等待、异常传播与取消，后者需手动处理；TaskGroup 是 Python 3.11+ 结构化并发原语，适用于强一致性场景。
asyncio.TaskGroup.create_task() 和 asyncio.create_task() 的本质区别
根本不是“哪个更好用”，而是“谁负责生命周期管理”——asyncio.create_task() 创建的是裸任务，你得自己 await 它、处理异常、防泄漏；而 asyncio.TaskGroup.create_task() 创建的任务被自动纳入结构化作用域，退出 async with 块时强制等待 + 统一异常传播 + 自动取消孤儿任务。
什么时候必须用 TaskGroup.create_task()？
当你需要确保并发任务“全成功才继续”或“任一失败就立刻中止其余任务”时，TaskGroup 是目前最安全的选择。它不是语法糖，是 Python 3.11+ 引入的结构化并发原语，解决的是传统 create_task() + 手动 await 容易漏掉错误处理、忘记清理、导致任务泄露的老问题。
- 多个网络请求必须全部完成，否则整个流程失败 → 用
TaskGroup - 启动后台监控任务，但主逻辑一出错就得立即停掉所有监控 →
TaskGroup自动帮你取消 - 想避免
asyncio.CancelledError没被捕获、任务静默消失 →TaskGroup保证异常不丢失 - 写测试时要严格控制任务生命周期 →
TaskGroup提供确定性退出点
为什么不能简单把 create_task() 换成 TaskGroup.create_task()？
因为调用位置和上下文完全不同：asyncio.create_task() 可以在任意协程里随时调，而 TaskGroup.create_task() 只能在 async with asyncio.TaskGroup() as tg: 块内使用，且该块本身就是一个协程作用域。强行替换会报 RuntimeError: no active task group。
-
create_task()是“发出去就不管了”，适合 fire-and-forget 场景（如日志上报、埋点） -
TaskGroup.create_task()是“进组即受管”，必须配合async with使用，不能脱离上下文 - 混用风险：在
TaskGroup块内再调asyncio.create_task()，那个任务就游离于组管理之外，不会被自动等待或取消
性能与兼容性现实约束
别为了“新”而用 TaskGroup：TaskGroup 要求 Python ≥ 3.11，而 create_task() 从 3.7 就有。如果你的项目还要支持 3.10 或更早版本，TaskGroup 直接不可用；即使支持，它也比裸 create_task() 多一层调度封装，开销略高——不过这点开销在 I/O 密集场景下几乎可忽略。
- 3.11+ 项目，且任务间有强依赖/强一致性要求 → 优先
TaskGroup - 需兼容旧版本，或只是启动几个独立后台任务 → 还是
create_task()更直接 - 用
asyncio.gather()已能满足需求（比如只等结果、不关心中间失败）→ 不必硬切TaskGroup
真正容易被忽略的点是：TaskGroup 不是“更高级的 create_task”，它是另一套并发模型——它强制你思考“这个并发块是否应该有自己的边界和契约”。一旦跨过这个思维门槛，很多诡异的异步 bug 其实就消失了。
