cryptography的RSA方法不能直接在async函数中调用，因其底层为同步阻塞的C实现，会卡住事件循环；正确做法是用asyncio.to_thread()将其封装进线程池执行。
为什么不能直接在 async 函数里调用 cryptography 的 RSA 方法
cryptography 底层是 C 实现，所有加密操作（如 private_key.sign()、public_key.verify()、PKCS1v15 填充）都是同步阻塞的。即使你把它包在 async def 里，也会卡住整个事件循环 —— 这不是“异步不支持”，而是它根本没提供非阻塞接口。
常见错误现象：
– CPU 密集型 RSA 操作期间，其他协程完全无法调度
– 使用 asyncio.to_thread() 却忘了传参或 await 返回值
– 误以为 load_pem_private_key(..., password=None) 是异步的，其实加载密钥本身也是同步的
用 asyncio.to_thread() 封装最简可行方案
Python 3.9+ 推荐方式：把耗时的加解密逻辑丢进线程池，避免阻塞事件循环。关键不是“改库”，而是“换执行上下文”。
-
to_thread()默认复用asyncio.get_event_loop().run_in_executor()的默认线程池，适合中低频调用（比如每秒几十次签名） - 不要在
to_thread()里重复加载密钥 —— 提前解析好private_key和public_key对象，只把sign()/verify()等计算步骤传进去 - 注意异常传递：
cryptography.exceptions.InvalidSignature会原样抛出，但需在await处捕获
import asyncio
from cryptography.hazmat.primitives.asymmetric import padding, rsa
from cryptography.hazmat.primitives import hashes, serialization
<h1>预加载（同步，只做一次）</h1><p>with open("key.pem", "rb") as f:
private_key = serialization.load_pem_private_key(f.read(), password=None)</p><p>async def sign_async(data: bytes) -> bytes:
return await asyncio.to_thread(
private_key.sign,
data,
padding.PKCS1v15(),
hashes.SHA256()
)
高并发场景下要控制线程池大小
默认线程池无上限，大量并发 to_thread() 可能创建过多线程，引发 OS 资源耗尽或 GIL 争抢加剧。尤其在 Web 服务（如 FastAPI）中，每个请求都触发 RSA 签名时必须限流。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 显式创建固定大小线程池：
concurrent.futures.ThreadPoolExecutor(max_workers=4) - 用
loop.run_in_executor(executor, ...)替代to_thread()，便于复用 - RSA 密钥长度影响显著：2048 位比 4096 位快约 3–4 倍，但安全性要求常迫使你用 3072 或 4096 —— 这时候更得压线程数
示例中若漏掉 executor 参数，就退化为默认无限池，线上容易雪崩。
别碰“纯异步 RSA”这种伪需求
网上有些方案试图用 aiocrypt 或自己用 asyncio.StreamReader 模拟非阻塞，本质都是障眼法 —— RSA 的数学运算无法拆成可暂停的子任务。所谓“异步封装”，99% 场景就是线程池 + 同步库。
真正该优化的点往往不在加密本身：
– 是否真的每次都要签名？能否缓存签名结果（带时间戳/nonce）？
– 是否可用 Ed25519 替代 RSA？它的签名更快且 cryptography 对它的支持更轻量（虽仍同步）
– 客户端是否支持 JWT？把签名逻辑下沉到网关层，业务 Python 服务只做验签（验证比签名快得多）
密钥加载、填充模式选择、哈希算法搭配这些细节，比“怎么 async”更容易出错，也更值得花时间核对。
