Python并发异常处理需按执行模型分层设计：线程异常须主动捕获并经Queue等传递；进程异常依赖exitcode或Future接口；asyncio中Task异常需显式检查exception()；通用策略强调状态隔离、幂等重试与显式超时。
Python并发编程中，异常处理的关键不在于“捕获所有错误”，而在于隔离故障影响范围、明确恢复边界、避免状态污染。多线程、多进程、asyncio 的异常传播机制差异大，统一用 try/except 包裹往往失效，必须按执行模型分层设计。
线程异常：无法跨线程传播，需主动捕获与传递
Thread 对象中抛出的异常不会自动冒泡到主线程，若不显式处理，错误会静默消失，导致任务“假成功”。正确做法是在 target 函数内捕获异常，并通过共享对象（如 queue、threading.Event 或自定义结果容器）传出错误信息。
- 使用 queue.Queue 存储结果或异常：worker 线程 put((result, None)) 或 put((None, exc))，主线程 get 后判断
- 避免在 run() 中直接 print/raise：这仅输出到线程 stdout，主线程不可见
- 配合 concurrent.futures.ThreadPoolExecutor 更安全：submit 返回 Future，调用 result() 时会重新抛出执行中异常
进程异常：子进程崩溃不中断父进程，但需主动回收与判错
Process 异常默认终止子进程，父进程需通过 is_alive()、exitcode 或 join(timeout) 感知失败。multiprocessing 模块不自动传递异常对象，只能靠 exitcode（整数）或共享内存标记错误。
- 子进程函数结尾加 try/except + os._exit(1) 显式退出非零码，便于父进程识别
- 使用 concurrent.futures.ProcessPoolExecutor 可复用 Future 接口，异常在 result() 调用时抛出
- 注意 pickle 限制：自定义异常类需可序列化，否则子进程无法还原异常类型
asyncio 异常：协程内未捕获则沿 await 链向上冒泡，但 Task 需显式检查
await 一个协程时，其内部异常会直接抛给调用方；但若协程作为 Task 被 create_task() 启动，则异常不会自动传播，而是使 Task 进入 done() 状态且 exception() 方法返回异常对象。
立即学习“Python免费学习笔记（深入）”；
- 对关键 Task 调用 task.exception() 检查是否失败，尤其在 asyncio.gather(..., return_exceptions=True) 场景下
- 避免 “fire-and-forget”：不 await、也不保存 Task 引用，会导致异常丢失且难以调试
- 使用 asyncio.shield() 保护关键清理逻辑不被 cancel 中断，但 shield 不捕获异常，仍需外层 try
通用恢复策略：状态隔离 + 幂等重试 + 显式超时
并发场景下，“恢复”不是重启整个流程，而是针对单个失败单元做可控回退。核心是避免共享状态被污染，确保每次尝试相互独立。
- 每个 worker 使用局部变量或线程/进程私有对象，不依赖全局 mutable 状态
- 网络或 I/O 操作封装为幂等函数（如带唯一 id 的请求），配合指数退避重试（可用 tenacity 库）
- 所有阻塞调用（queue.get、future.result、await wait_for）必须设 timeout，防止一个卡死拖垮整体
