不能直接在 asyncio 中用 requests.get，因为它是阻塞式调用，会卡住 event loop，破坏异步并发性；应通过 loop.run_in_executor 或 asyncio.to_thread（Python 3.9+）在线程池中执行，避免阻塞主循环。
为什么不能直接在 asyncio 中用 requests.get？
因为 requests.get 是完全阻塞的，一旦调用就会卡住当前 event loop，整个异步程序的并发优势瞬间归零。你可能看到 CPU 占用低、响应变慢、甚至超时堆积——这不是代码写错了，是根本模型冲突。
常见错误现象：RuntimeWarning: coroutine 'sleep' was never awaited（实际是其他协程被 requests 拖垮了），或者 asyncio 任务排队等得比同步还久。
核心思路：把阻塞操作移出 event loop，交给线程池执行，再用 loop.run_in_executor 包装成协程等待结果。
如何用 run_in_executor 包装 requests.get？
最轻量、最可控的方式就是手动包装，不依赖额外库。关键点在于：必须传入 executor 实例（推荐 concurrent.futures.ThreadPoolExecutor），且 requests 调用要在普通函数里完成，不能在里面 await 任何东西。
立即学习“Python免费学习笔记（深入）”；
实操建议：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 显式创建线程池（避免复用全局默认池，防止被其他模块干扰）：
executor = ThreadPoolExecutor(max_workers=10) - 定义纯同步函数封装 requests：
def sync_get(url): return requests.get(url, timeout=10).json() - 在协程中调用：
data = await loop.run_in_executor(executor, sync_get, "https://httpbin.org/json")
- 别忘了在应用退出前
executor.shutdown(wait=True)，否则可能进程 hang 住
asyncio.to_thread 和 Python 版本陷阱
Python 3.9+ 提供了 asyncio.to_thread，看起来更简洁：
data = await asyncio.to_thread(requests.get, url)但它底层仍用
ThreadPoolExecutor，且默认不传 max_workers，会复用全局线程池——这在高并发场景下极易成为瓶颈。
容易踩的坑：
- Python AttributeError: module 'asyncio' has no attribute 'to_thread'
- 没控制线程数，大量请求导致线程创建爆炸（尤其在容器或低内存环境）
-
to_thread不支持传 keyword-only 参数（比如timeout=必须写成位置参数），而requests.get的**kwargs很多，容易参数错位
requests.Session 复用与线程安全
每次新建 requests.Session() 开销不小，但直接复用全局 Session 在多线程下有风险：虽然官方文档说 “Session instances are thread-safe”，但前提是每个线程调用自己的 Session 实例——跨线程共享同一个实例并同时调用 .get()，可能触发连接池竞争或 SSL 上下文冲突。
稳妥做法：
- 为每个线程池 worker 创建独立 Session（在
sync_get内部初始化） - 或使用
threading.local()绑定 Session 到线程，但要注意生命周期管理 - 避免在协程层共享 Session 对象后传进
run_in_executor，这是典型的隐式共享
真正难处理的从来不是“怎么调用”，而是连接复用、DNS 缓存、SSL 会话复用这些底层细节在线程切换后是否还能生效——它们不会报错，但会让性能曲线变得诡异。
