Python并发异常处理需隔离影响、结构化捕获、结果聚合与分层策略：任务级用try/except包装为Result；非关键路径用suppress或装饰器兜底并记录日志；gather设return_exceptions=True获取全部结果；按transient/permanent/system三类错误分别重试、告警或熔断。
Python并发编程中，异常处理不能简单套用单线程逻辑——多个任务并行执行时，一个任务出错不该拖垮全局，更不该静默失败。关键在于隔离异常影响范围、明确恢复边界，并让错误可观察、可重试、可兜底。
任务级异常隔离：避免协程/线程间连锁崩溃
在asyncio或threading中，未捕获的异常会终止当前执行单元（如协程或线程），但默认不会传播到主线程或事件循环外。问题常出在“以为没人管，其实没人接”：
- asyncio.create_task() 启动的协程若抛出未捕获异常，会以警告形式输出到日志，但任务直接结束，不中断其他协程——这是隔离，但容易被忽略
- threading.Thread 若 run() 中异常未捕获，线程静默退出，主线程无法感知；需通过设置 daemon=False + 主动 join() + 捕获 threading.excepthook 或自定义 Thread 子类重写 run()
- 推荐做法：每个并发任务入口处加一层 try/except，把原始异常包装为业务可识别的 Result 对象（含 success、value、error）
结构化异常捕获：用 contextlib.suppress 或自定义装饰器统一兜底
不是所有异常都需要层层向上抛。对非关键路径（如日志上报、缓存更新、埋点发送），应主动抑制干扰性异常，保障主流程稳定：
- 轻量场景用 contextlib.suppress(IOError, asyncio.TimeoutError)，避免因网络抖动导致主逻辑中断
- 中等复杂度可用装饰器封装重试+降级逻辑，例如 @safe_call(fallback=lambda: DEFAULT_DATA, retries=2, backoff=0.1)
- 注意：suppress 不等于忽略，要配合日志记录（如 logging.warning("Cache update failed", exc_info=True)），确保可观测
结果聚合与错误归因：用 asyncio.gather(..., return_exceptions=True) 精准定位失败项
批量并发调用（如同时请求多个API）时，传统 gather 遇到第一个异常就中断，无法获取其余结果。开启 return_exceptions=True 后，异常也会作为普通返回值传回，便于后续分析：
立即学习“Python免费学习笔记（深入）”；
- 返回列表中每个元素可能是正常结果，也可能是 Exception 实例，用 isinstance(x, Exception) 判断
- 结合 enumerate 可定位具体是第几个任务失败，再关联原始参数做归因（如 url_list[i] 对应的请求出错）
- 适合构建“尽力而为”的批处理服务，比如同步用户数据时，部分失败不影响整体进度，只需单独告警并补偿
恢复策略分层设计：按错误类型选择重试、降级或熔断
并发异常不是统一处理，要区分 transient（临时）、permanent（永久）、system（系统级）三类：
- Transient 错误（如 ConnectionError、503、超时）：指数退避重试（推荐 tenacity 库），限制总耗时和次数
- Permanent 错误（如 404、401、JSONDecodeError）：立即失败，记录错误上下文，触发告警或人工介入
- System 错误（如 asyncio.CancelledError、MemoryError）：通常需终止当前任务流，清理资源（关闭连接、释放锁），防止雪崩
并发异常处理不是堆 try/except，而是建隔离墙、设检查点、留逃生通道。写法不复杂，但容易忽略恢复语义和可观测性设计。
