使用 asyncio.gather(..., return_exceptions=True) 可确保单个协程抛出异常时不影响其他并发任务的执行，配合信号量控制并发数，即可构建健壮的异步任务池。
使用 `asyncio.gather(..., return_exceptions=true)` 可确保单个协程抛出异常时不影响其他并发任务的执行，配合信号量控制并发数，即可构建健壮的异步任务池。
在基于 asyncio 构建异步任务池时，一个常见误区是：在 worker 协程内部主动捕获并“吞掉”异常（如用 try/except 返回 None），反而会破坏 asyncio.gather 对异常传播的控制逻辑，导致任务调度行为异常。你观察到“task 3 不执行”的现象，并非 gather 中断了调度，而是因为——当所有任务被 await 统一等待时，gather 默认会在任一子任务抛出未捕获异常时立即中断整个等待过程（除非显式启用 return_exceptions=True）。
但关键点在于：return_exceptions=True 的作用前提是——异常必须真实地从协程中抛出（即不被内部 except 拦截）。一旦你在 worker 内部用 try/except 捕获并静默处理（例如 return None），该协程就不会抛出异常，gather 就无法将其识别为“失败任务”，也就无法将异常对象存入结果列表；更严重的是，这种写法可能掩盖调度逻辑问题，甚至引发难以调试的竞态行为。
✅ 正确做法是：
-
移除 worker 内部不必要的
try/except，让业务异常自然向上抛出； -
始终使用
return_exceptions=True调用asyncio.gather，使所有任务（无论成功或失败）的结果统一返回为列表； - 在主流程中对结果进行类型判断，区分正常返回值与异常实例。
以下是优化后的完整示例：
import asyncio
async def worker(semaphore, task_id):
async with semaphore:
# 异常应直接抛出，不在此处拦截
if task_id == 2:
raise ValueError("Something went wrong in task 2")
await asyncio.sleep(1)
print(f"Task {task_id} completed")
return f"Result from task {task_id}"
async def main():
# 限制最多 2 个并发任务
semaphore = asyncio.Semaphore(2)
tasks = [worker(semaphore, i) for i in range(4)]
# 关键：return_exceptions=True 确保所有任务完成后再统一处理结果
results = await asyncio.gather(*tasks, return_exceptions=True)
# 统一检查每个结果
for i, result in enumerate(results):
if isinstance(result, BaseException):
print(f"Task {i} raised an exception: {repr(result)}")
else:
print(f"Task {i} returned: {result}")
if __name__ == "__main__":
asyncio.run(main())
? 输出示例：
Task 0 completed
Task 1 completed
Task 3 completed
Task 0 returned: Result from task 0
Task 1 returned: Result from task 1
Task 2 raised an exception: ValueError('Something went wrong in task 2')
Task 3 returned: Result from task 3
⚠️ 注意事项：
- 不要混用
asyncio.run()与已存在的事件循环（如 Jupyter、某些 Web 框架环境），否则会触发RuntimeError: asyncio.run() cannot be called from a running event loop。生产环境中建议使用asyncio.get_event_loop().run_until_complete(main())或适配框架的生命周期管理。 - 若需对异常做差异化重试、降级或日志增强，应在
main()中针对result做判断后处理，而非在worker中提前捕获。 -
semaphore保证了并发数限制，而gather + return_exceptions=True保障了任务间的错误隔离性——二者结合，才是高可用异步任务池的核心模式。
通过这种方式，你既能精准控制并发压力，又能实现“故障隔离”：一个任务崩溃，绝不阻塞其余任务执行，真正达成弹性、可观测、易维护的异步工作流。
