首先，最簡單的辦法就是搜一下這個(gè)庫的源碼里是否出現(xiàn)了 asyncio 或 async def 的字樣，如果沒有出現(xiàn)則幾乎可以證明這個(gè)庫沒有對 asyncio 有做特別的支持。為了徹底證實(shí)，還應(yīng)仔細(xì)閱讀其代碼，查看關(guān)鍵 I/O 部分是如何實(shí)現(xiàn)的。

對于暫不支持 asyncio 的第三方庫，可以按以下步驟依次排查：

1. 確認(rèn)其 I/O 時(shí)間比例是否占到大部分。比如用 SQLAlchemy 時(shí)，如果能基本上確保數(shù)據(jù)庫操作都是瞬時(shí)的，那么理論上是可以任由其阻塞主線程的。而對于明顯 I/O 占大多數(shù)時(shí)間且時(shí)間不可預(yù)測的，比如 requests，就不能讓其成為性能瓶頸；
2. 確認(rèn)其 I/O 的并發(fā)能力是否會成為瓶頸。比如說還是用到了 requests，但平均下來每 10 分鐘才會發(fā)一個(gè)請求，其他時(shí)間主要都用在數(shù)據(jù)庫計(jì)算上了，那么完全可以把 requests 放到線程池里去做；
3. 確實(shí)需要異步了，首先查找其 asyncio 的擴(kuò)展，有時(shí)會有單獨(dú)的庫做 asyncio 支持，比如 peewee_async；
4. 查找其 asyncio 的替代，比如用 asyncpg 替代 psycopg2；
5. 實(shí)在沒有了，再次看看線程池的解決方案對性能的影響到底是多少；
6. 如果線程池確實(shí)不行，此時(shí)一般碰到的庫多半都會有自己的并發(fā)模型，走到這一步意味著該并發(fā)模型并不能兼容 asyncio。此時(shí)，可以看看并發(fā)庫對 asyncio 的支持，比如 gevent 與 asyncio 的橋接；
7. 自己改了它吧，或者造新的輪子。