在Quart中用run_sync包装requests库请求引发间歇性故障排查

核心原因：同步阻塞与异步事件循环的冲突 #

用run_sync包装同步的requests调用，本质是把阻塞IO丢给线程池处理，但在uvloop+UvicornWorker的组合下，主要有以下场景会触发CancelledError：

1. 请求超时被框架主动取消 #

Quart/Uvicorn默认存在请求超时配置（通常为60秒），如果requests的线程池任务耗时接近或超过这个阈值，框架会主动取消对应的异步任务，抛出CancelledError。而同步模式下，Flask的请求处理是单线程阻塞逻辑，不会直接中断同步调用，因此不会出现这类错误。

2. 线程池资源耗尽导致任务排队被取消 #

当并发请求量较高时，run_sync默认的线程池（大小一般为CPU核心数×5左右）会被占满，新任务进入排队队列。如果排队时间过长，或者客户端提前中断请求，框架可能会取消排队中的线程池任务，触发错误。

3. uvloop对线程池任务的调度特性 #

uvloop作为高性能事件循环，对线程池任务的调度更敏感。如果requests调用出现阻塞（比如DNS解析缓慢、目标服务响应延迟），uvloop可能判定任务无响应，进而触发取消逻辑——这类情况在默认asyncio事件循环中出现概率更低。

解决建议 #

• 替换为异步HTTP客户端：用aiohttp替代requests，完全适配异步框架，从根源避免同步阻塞带来的冲突。虽然需要修改部分代码，但长期维护成本更低。
• 调整线程池大小：通过Quart的app.config['RUN_SYNC_THREADS']配置，或在run_sync时指定线程池，比如await run_sync(requests.get, url, executor=ThreadPoolExecutor(max_workers=20))，缓解资源耗尽问题。
• 增加请求超时控制：给requests调用明确设置超时时间（如requests.get(url, timeout=10)），确保线程池任务不会无限阻塞，减少被框架取消的概率。
• 禁用uvloop测试：临时切换回默认的asyncio事件循环，观察CancelledError是否消失，验证是否由uvloop的调度特性导致问题。

内容的提问来源于stack exchange，提问作者kdavh