多线程非万能，仅适用于I/O密集型耗时操作；CPython中计算密集型任务应选multiprocessing或asyncio；推荐用ThreadPoolExecutor控制并发，避免共享数据，必要时加锁；Web框架中优先用异步或后台任务而非裸线程。
多线程不是万能解药，先看是不是真需要
API接口开发中，遇到耗时操作（比如调用第三方HTTP服务、读写文件、数据库慢查询）才考虑多线程。纯计算密集型任务用多线程反而更慢——CPython有GIL限制，此时该用multiprocessing或异步（asyncio）。简单返回JSON、做校验、查缓存这些，单线程足够快，加线程还可能引入竞态和调试困难。
用concurrent.futures.ThreadPoolExecutor最省心
别手写Thread+Queue那一套。直接上ThreadPoolExecutor，简洁、可控、自带异常传播：
- 指定max_workers控制并发数（别设太大，一般设为CPU核数×2～5，结合I/O等待时间调整）
- 用submit()提交单个任务，返回Future对象；用map()批量处理同结构任务
- 记得用as_completed()或wait()等结果，避免主线程提前退出
线程安全：共享数据必须加锁，但尽量少共享
多个线程读写同一变量（比如全局计数器、缓存字典）极易出错。解决方式有两个方向：
- 不共享：每个线程处理独立数据，结果最后汇总（推荐）
- 加锁保护：用threading.Lock()或threading.RLock()包裹临界区，注意锁粒度别太粗，也别忘记释放（用with语句最安全）
例如统计并发请求中某类错误次数，不要直接error_count += 1，而要：
立即学习“Python免费学习笔记（深入）”；
lock.acquire()
try:
error_count += 1
finally:
lock.release()
或者更简洁：with lock: error_count += 1
Web框架里谨慎开线程，优先用异步或后台任务
Flask/FastAPI等同步框架中，在路由函数里直接起线程容易失控：请求结束但线程还在跑，可能导致资源泄漏或返回不一致。更稳妥的做法是：
- 把耗时逻辑拆出去，用Celery/RQ做后台任务，API立即返回任务ID
- 用FastAPI的BackgroundTasks轻量级兜底（适合秒级、无状态的小任务）
- 真要用线程，确保用ThreadPoolExecutor且生命周期受控，别让线程活过响应周期
基本上就这些。多线程本身不复杂，但容易忽略上下文和边界——想清楚“谁启、谁等、谁清理”，比学会start()重要得多。
