Python并发设计的核心是根据任务类型、资源约束和可维护性做有意识取舍：I/O密集用异步或线程，CPU密集必须用多进程；需控制并发规模、避免状态共享、强化可观测性，并优先明确责任边界。
Python并发设计的核心不是堆砌工具，而是根据任务类型、资源约束和可维护性做有意识的取舍。盲目用asyncio或开几百个线程，往往让系统更慢、更难调试。
明确任务类型：I/O密集还是CPU密集？
这是所有并发决策的起点。I/O密集型（如HTTP请求、数据库读写、文件操作）适合异步或线程；CPU密集型（如数值计算、图像处理）必须用多进程，否则GIL会锁死并发收益。
- 不确定时，先用time.perf_counter()测单任务耗时，再观察CPU使用率——持续接近100%说明是CPU瓶颈
- 混合型任务（如下载+解析JSON）要拆解：下载用asyncio，解析用concurrent.futures.ProcessPoolExecutor
- 避免把CPU工作塞进async函数里，这会让整个事件循环卡住
控制并发规模：数量不是越多越好
连接池、线程数、协程并发量都需设上限。无限制增长只会触发系统级限制（文件描述符、内存、TIME_WAIT堆积），反而降低吞吐。
- HTTP客户端默认连接池大小通常20–100足够；爬虫类应用建议3–10个并发协程
- threading.Thread建议不超过系统CPU核心数×2；multiprocessing.Pool默认用cpu_count()，但IO-heavy场景可适度上调
- asyncio.Semaphore是控制协程并发最直接的方式，配合timeout避免死等
状态与共享：少共享，就安全
Python并发的多数bug源于意外的状态共享。线程间用queue.Queue或threading.local；协程间避免全局变量或类实例属性跨await点修改；多进程间优先用multiprocessing.Manager或消息队列，而非直接传对象。
立即学习“Python免费学习笔记（深入）”；
- asyncio不支持threading.local，可用contextvars.ContextVar保存请求级上下文（如trace_id）
- 用dataclass + frozen=True定义不可变配置，减少运行时状态误改风险
- 日志记录统一走structlog或logging.getLogger()，别在多个线程/协程里各自open()文件
可观测性不能事后补
并发程序出问题往往静默失败或偶发超时。从第一行代码起就要埋点：记录协程/线程ID、关键路径耗时、异常类型、当前并发数。
- 用asyncio.create_task()代替直接await，便于task.cancel()和监控生命周期
- logging.getLogger().info(f"req_id={req_id} step=fetch status=ok time={dt:.3f}s") 比 print()强十倍
- 用trio或anyio替代原生asyncio可获得更好错误栈和取消语义，尤其适合中大型项目
不复杂但容易忽略。设计阶段想清楚“谁在什么时候做什么”“失败了谁负责清理”“下游扛不扛得住”，比选哪个库重要得多。
