python aiohttp

### 聊聊 Python 的 aiohttp：一个写异步 HTTP 的家伙

作为 Python 开发者，平常写网络请求，最头疼的是啥？等 响应 的时候，程序卡在那儿，啥也干不了。十年前，大部分人会甩一句“用 gevent 啊”，或者“开线程池”。但现在回头看看，aiohttp 成了很多人方案里的主角。它不是新鲜玩意儿，2014 年左右就有了，但直到 Python 3.5 正式支持 async/await 语法后，它才真正变得顺手。

1，它到底是什么

aiohttp 就是一组用来处理 HTTP 的异步工具库。说简单点，它同时保留了两个身份：一个是可以写异步客户端的库，另一个是能跑异步服务端的框架。比如你用 requests 写过爬虫，那 aiohttp 的客户端版就是它的异步替代品。如果你用过 Flask 或者 FastAPI，aiohttp 的服务端能力相当于一个轻量级的替代品。

有个细节值得注意——很多人以为它只能发请求，其实它能同时做服务端。比如你平时写的一个小工具，需要对外提供一个 RESTful 接口，同时又需要不间断拉取别的服务的数据，这时候 aiohttp 就特别合适，因为一个事件循环里就能跑两套逻辑，不用开两个进程来回传数据。

2，它能做什么

简单列举几个典型场景：

写高并发爬虫。一个简单的例子就是爬取几百个网页。用 requests 写，开几十个线程，内存容易爆，管理也麻烦。用 aiohttp，一个协程搞定，线程数基本不变，但请求并发数能调到上千。很多数据采集工具底层的 HTTP 请求就是封装了 aiohttp。

写异步 API 网关或代理。比如需要将外部 API 的数据透传给前端，同时做缓存、限流、合并请求，aiohttp 的服务端模式就特别顺手。国内不少大厂的中台化网关，一些核心路由层用的就是 aiohttp。

写 WebSocket 推送服务。aiohttp 原生支持 WebSocket，长链接管理非常简单。像一些即时聊天组件、实时数据看板、交易推送，轻量级的场景用它就够了，撑个几千链接问题不大。

做微服务内部通信。尤其是基于 HTTP/2 的跨服务调用，aiohttp 也算顺手。虽然现在很多人转投 gRPC，但 aiohttp 的侵入性更小，搭个小服务几十行代码搞定，非常适合尝试新想法。

3，怎么使用

大多数人刚接触 aiohttp 时，会先看到一长串的异步代码，感觉和 requests 差别很大。实际上核心只有一个：所有涉及 I/O 的操作（发送、接收、连接建立）都需要用 await。

客户端用法，以拉取一个典型的 JSON API 为例：

importaiohttpimportasyncioasyncdeffetch_data(url):asyncwithaiohttp.ClientSession()assession:asyncwithsession.get(url)asresp:returnawaitresp.json()asyncdefmain():url="https://api.github.com/users/octocat"data=awaitfetch_data(url)print(data["login"])asyncio.run(main())

这段代码看起来简单，其实藏了一个细节：aiohttp.ClientSession 是需要复用的。每次请求都创建一个新 session，会导致每次都要重新建立 SSL 握手和连接池，效率就没了。

服务端用法，比如写一个小接口处理 JSON：

fromaiohttpimportwebasyncdefhandle_user(request):user_id=request.match_info.get('id')# 假设这里去数据库查returnweb.json_response({"user_id":user_id})app=web.Application()app.router.add_get('/user/{id}',handle_user)web.run_app(app,host='127.0.0.1',port=8080)

这里的 app 对象和 Flask 和 FastAPI 的 app 类似，但底层基于 asyncio，路由匹配、请求解析、响应序列化都跑在同一个事件循环里。

4，最佳实践

说了这么多，我踩过的坑帮各位整理几处。

连接池大小要主动设。aiohttp 的 ClientSession 默认连接池上限是 100，并发多的话很容易耗尽。经验值是单机高并发时开到 300-500，但别无限量增大，否则本机连接数和内存会扛不住。合理做法：在创建 session 时传入connector = aiohttp.TCPConnector(limit=500)。

给 session 加超时控制。aiohttp 默认不设总请求超时。遇到个别响应慢的 API 会把整个爬虫拖垮。建议给ClientTimeout(total=30)统一设一个软超时，出现超时了平滑重试。

小心异常处理。aiohttp 的异常体系比 requests 复杂点。客户端模式常见的异常有aiohttp.ClientConnectorError（连不上服务器）、asyncio.TimeoutError（超时）、aiohttp.ClientResponseError（状态码异常）。建议在每个重要请求外层加try/except捕获。

避免在循环中重复创建 session。很多人第一次写 aiohttp 代码时，会把async with ClientSession()放在每一个请求里面。但这会导致每个请求都重新创建连接池，严重降低效率。正确做法是全局一个 session，或者一个 session 对象复用一段时间后销毁重开。

服务端模式下尽量用中间件解耦。比如日志打印、请求验证、限流，都可以通过@web.middleware装饰器加在 app 上，而不是在每个处理函数里重复写。

5，和同类技术对比

在实际选型时，经常有人会拿 aiohttp 和几个东西对比。

对比 requests + concurrent.futures。后者属于传统阻塞式 I/O 加线程池。优点是理解和迁移成本低，适合只处理几十个并发的小脚本。一旦并发超过上千，线程切换开销明显，而且 Python 的 GIL 在线程池场景下依然会带来一定限制。相反 aiohttp 本身就是单线程非阻塞，大量长连接场景下内存和调度开销都更低。

对比 httpx。httpx 是最近几年兴起的库，既支持同步也支持异步，而且 API 设计更接近 requests，学习曲线平滑。不过它的异步底层底层依赖 httpcore，而 aiohttp 完全基于 asyncio 和 C 扩展（底层由 uvloop/cython 加速）。实测下来，httpx 在高并发场景下性能和 aiohttp 差距不大，但资源占用上 httpx 比 aiohttp 高一点，尤其连接数一上去，内存增长更快。所以超大规模爬虫、网关这类场景，aiohttp 仍有一席之地。

对比 FastAPI。FastAPI 作为服务端框架，它的底层是 Starlette（也是基于 asyncio），而 Starlette 又依赖uvicorn等 ASGI 服务器。aiohttp 则直接自带 web 服务器（基于asyncio的底层 I/O）。如果只是想写一个小型代理或工具类服务，aiohttp 的起步更快，不用折腾 uvicorn/gunicorn。但 FastAPI 的优势在于自动生成 API 文档和数据校验（Pydantic），适合写复杂的企业级应用。

对比 gRPC。如果谈的是跨语言、跨服务的高性能 RPC 通信，gRPC 在序列化效率和协议定义方面都比 aiohttp 更专业。但 aiohttp 胜在 HTTP 生态兼容，和后端接起来不需要定义 proto 文件，参数用 JSON 传递，对前端和测试更友好。大部分内部工具选 aiohttp 比 gRPC 快得多，代价小。

最后，说句心里话：aiohttp 是一种“学一点，就能干很多”的库。但千万别试图用它做所有事，比如跑大流量文件上传、长连接消息队列，还是得配合其他组件。关键是在 I/O 密集型场景下，它能给你省下不少服务器和开发成本。希望这些内容，能帮各位在写下一个异步项目时心里更有数。