aiohttp HTTPS连接池泄漏本质是SSL上下文滞留与session复用不当：必须用async with统一管理ClientSession生命周期，显式复用SSLContext，禁止单次请求新建session，并升级multidict≥4.5.2以修复引用环。
HTTPS连接未关闭导致的连接池泄漏
aiohttp 在 HTTPS 请求中若未正确关闭 ClientSession 或复用不当，会持续持有 SSL 连接句柄和 TLS 上下文，这些对象在 CPython 中不被立即回收，尤其在频繁创建 session 的场景下，内存增长明显且不回落。这不是“泄露”而是“滞留”——连接池里的空闲 HTTPS 连接因未触发超时或未显式 close，长期驻留于内存。
常见现象：htop 观察到进程 RSS 持续上涨；tracemalloc 显示大量 ssl.SSLContext、aiohttp.connector.TCPConnector 和 asyncio.sslproto.SSLProtocol 实例堆积；lsof -p PID | grep SSL 可见数百个处于 ESTABLISHED 状态但无活跃流量的连接。
- 必须用
async with aiohttp.ClientSession()包裹整个请求生命周期，不能只包单个session.get() - 禁止在循环内新建
ClientSession，例如：for url in urls: async with aiohttp.ClientSession() as s: await s.get(url)—— 这会为每个请求新建 session，连接完全无法复用 - 若需跨协程复用 session，确保它由外层生命周期统一管理（如 FastAPI 的
lifespan或全局 singleton），并在应用退出前调用await session.close()
SSLContext 重复创建引发的对象堆积
每次新建 TCPConnector 时若未复用 ssl.SSLContext，aiohttp 默认会创建新上下文实例。而 SSLContext 是重量级对象，内部持有证书缓存、密钥材料、C-level 引用等，频繁重建会显著增加内存开销，且 GC 难以及时清理。
关键点：aiohttp 本身不自动复用 SSLContext，即使你传入相同参数，只要没显式传递同一实例，就会新建。
立即学习“Python免费学习笔记（深入）”；
- 显式创建并复用一个
ssl.SSLContext实例：import ssl; ctx = ssl.create_default_context()，然后传给TCPConnector(ssl=ctx) - 避免使用
ssl=True（默认行为），它每次都会新建上下文；也不要传ssl=ssl.create_default_context()到 connector —— 这仍是每次新建 - 若需自定义验证（如跳过证书校验），仅在调试环境用
ssl=False；生产环境应复用带 CA bundle 的上下文，并设ctx.check_hostname = True
multidict 和 yarl 版本兼容性引发的引用滞留
历史问题已修复，但仍在部分旧部署中残留：multidict==4.5.1 在处理 HTTPS 响应头时存在引用计数异常，导致 yarl.URL 对象与 multidict.CIMultiDict 形成隐式循环引用，GC 无法回收。该问题在 multidict>=4.5.2 中修复，但若项目锁死旧版本或依赖间接引入，仍会触发。
验证方式：pip show multidict yarl aiohttp，检查是否含 multidict==4.5.1；再用 objgraph.show_most_common_types(limit=20) 查看是否有大量 yarl.URL 或 multidict._multidict._CIMultiDict 实例。
- 升级至
multidict>=4.5.2（推荐>=6.0.0）和yarl>=1.9.0 - 若无法升级，临时规避：在响应处理后手动删除引用，例如
del resp.url; del resp.headers（仅对单次响应有效，不治本） - 注意：aiohttp 3.9+ 已强制要求
multidict>=6.0.0，旧版用户升级 aiohttp 本身也能一并解决
异步上下文未清理导致的 contextvars 残留
HTTPS 请求常伴随重定向、认证、Cookie 处理等复杂流程，aiohttp 内部会通过 contextvars 传递请求上下文（如 current_trace、current_request_info）。若协程因异常中断或未 await 完整响应流，这些上下文变量可能滞留在 event loop 中，尤其在 TaskGroup 或 asyncio.create_task() 场景下，形成弱引用环，拖慢 GC。
典型表现：tracemalloc 显示大量 contextvars.Context 实例，分配位置指向 asyncio/tasks.py 或 aiohttp/client.py。
- 始终 await 完整响应体，避免只读 header 就丢弃
resp：用await resp.text()或await resp.read()，而非仅访问resp.status - 对流式响应（如
resp.content），必须用async for chunk in resp.content.iter_any():并确保循环自然结束，或显式调用await resp.release() - 在关键路径末尾插入
gc.collect()（仅限紧急缓解），更稳妥的是用asyncio.shield()包裹整个请求逻辑，防止被 cancel 中断
真正难缠的不是 HTTPS 协议本身，而是它放大了连接管理、上下文生命周期和第三方库引用环的缺陷——任何一个环节松动，都会在 TLS 握手、证书验证、加密缓冲区这些底层模块上留下难以释放的痕迹。
