run_in_executor是绕过阻塞的首选方案，因它将同步函数移交线程池/进程池执行，避免阻塞事件循环；i/o密集型用默认threadpoolexecutor，cpu密集型须显式传processpoolexecutor，并必须await等待结果。
为什么 run_in_executor 是绕过阻塞的首选方案
Python 的 asyncio 事件循环本身不能执行耗时同步操作（比如文件读写、数据库查询、CPU 密集计算），一旦在协程里直接调用，整个事件循环就会卡住。你不是要“改写”所有同步函数为异步，而是需要一种安全的“隔离执行”机制——run_in_executor 正是为此设计：它把同步函数扔进线程池（或进程池）运行，不抢占事件循环线程，协程可继续调度其他任务。
注意：run_in_executor 默认使用 ThreadPoolExecutor，适合 I/O 密集型同步调用；对 CPU 密集型任务，需显式传入 ProcessPoolExecutor，否则仍可能拖慢主线程。
怎么正确调用 run_in_executor 并传参
常见错误是直接传执行结果（如 loop.run_in_executor(None, time.sleep(2))），这会导致同步函数当场执行，失去异步意义。必须传函数对象和参数分开：
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
-
loop.run_in_executor(None, sync_func, arg1, arg2)—— 参数按顺序传递 - 若需 keyword 参数，用
functools.partial或 lambda 包装：lambda: sync_func(x=1, y="a") - 第一个参数为
executor，传None表示用默认线程池；自定义池需提前创建并复用，避免反复开销 - 返回的是
asyncio.Future，必须await才能得到结果，不能直接 print 或赋值给普通变量
哪些同步函数不适合用 run_in_executor 处理
不是所有阻塞都能靠线程池“蒙混过关”。以下情况会出问题：
- 依赖线程局部存储（
threading.local）的库（如某些老版本 ORM 连接管理），在线程池中行为不可控 - 持有全局锁或文件描述符的 C 扩展（如部分图像处理库），多线程并发调用可能崩溃或返回脏数据
- 函数内部启动了子进程并等待其退出（如
subprocess.run(..., check=True)），虽能跑通，但大量调用会快速耗尽系统进程数 - 本就基于 asyncio 实现的“伪同步”接口（如
aiofiles.open返回的对象不支持read()，只能用aread()），强行丢进 executor 反而降低性能
线程池大小与生命周期容易被忽略的细节
默认 ThreadPoolExecutor 最大线程数是 min(32, (os.cpu_count() or 1) + 4)，对高并发 I/O 场景往往不够，且未设置 max_workers 时无法预测实际并发上限。
- 建议显式创建带固定大小的池：
executor = ThreadPoolExecutor(max_workers=10)，并在应用生命周期内复用 - 忘记调用
executor.shutdown(wait=True)可能导致程序退出时线程被强制杀掉，引发资源泄漏（如数据库连接未 close） - 若协程频繁创建新 executor 而不复用，会触发大量线程创建/销毁开销，吞吐反而下降
- 在
asyncio.run()结束后，手动创建的 executor 若未 shutdown，Python 解释器退出时不会自动清理其后台线程
真正麻烦的从来不是调不调得动 run_in_executor，而是没想清楚那个同步函数到底在哪个上下文里运行、持有哪些隐式状态、以及它的资源是不是真的能被多个线程安全共享。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
