Python并发设计核心是控制复杂度而非堆砌工具：按IO特征选模型（asyncio适配IO密集、multiprocessing用于CPU密集），避免混用模型，优先用通信代替共享状态，显式处理错误，强制超时与限流。
处理错误，强制超时与限流。Python并发设计的核心不是堆砌工具，而是用最轻量、最贴合场景的方式解决问题。过度使用线程、协程或进程，反而会放大调试难度、资源争用和逻辑耦合——控制复杂度，比实现并发本身更重要。
按IO特征选模型，不为“高级”而升级
多数Web服务、API调用、文件读写属于IO密集型，asyncio + aiohttp/aiofiles足够高效；CPU密集任务（如数值计算、图像处理）才需考虑multiprocessing。混用threading和asyncio（比如在协程里调用阻塞IO）会破坏事件循环，引入隐性同步点，让性能和可读性双降。
- HTTP请求多且慢？优先用
aiohttp.ClientSession，别用requests配线程池 - 要并行处理100个本地JSON文件？
concurrent.futures.ProcessPoolExecutor可能不如单线程+json.load快——先测再选 - 有遗留同步库（如某些数据库驱动）必须调用？用
loop.run_in_executor隔离，但明确标注“此处退化为同步”
共享状态能免则免，通信优于共享
全局变量、类属性、模块级dict在并发下极易引发竞态。Python的GIL不保护用户数据结构，list.append或dict[key] = value都不是原子操作。
- 协程间传递数据？用
asyncio.Queue，它线程安全且适配异步生命周期 - 多进程需要共享配置？序列化后通过
multiprocessing.Manager.dict()或启动参数注入，而非动态修改全局dict - 真需计数/开关状态？用
asyncio.Lock或multiprocessing.Value，并把临界区缩到最小——例如只锁赋值，不锁整个计算过程
错误处理必须显式覆盖，不依赖“自动传播”
协程中未捕获异常会静默消失；线程崩溃默认不中断主线程；子进程退出码被忽略就等于失败不可见。并发放大了错误隐蔽性。
- 所有
asyncio.create_task()都应搭配asyncio.gather(..., return_exceptions=True)或单独await并try-catch - 用
concurrent.futures.Executor.submit()时，务必调用future.result()（它会重新抛出执行中的异常） - 子进程启动后，检查
proc.returncode，非零时记录stderr输出——不要只靠proc.wait()返回True/False
监控与限流是并发系统的标配，不是优化项
没有超时、没有并发数限制、没有成功率统计的并发，等于裸奔。复杂度常来自失控的资源膨胀，而非代码本身。
- 所有网络调用加
timeout：aiohttp用timeout=ClientTimeout(total=5)，requests用timeout=(3, 7) - 限制最大并发数：
asyncio.Semaphore(10)包住关键协程，ThreadPoolExecutor(max_workers=8)设合理上限 - 关键路径埋点：记录每批任务的平均耗时、失败率、队列堆积深度——用
time.perf_counter()比time.time()更准
不复杂但容易忽略。
