requests中开启长连接需使用session对象，因其内置连接池默认支持keep-alive；但需注意服务端是否真正支持、连接池需手动关闭、并发时需调大pool_maxsize，并非所有场景都适用长连接。
长连接在 requests 里怎么开，又为什么不能乱开
requests 默认是短连接，每次 requests.get() 都会新建 TCP 连接、发完就关。想复用连接，得自己配 Session——它内部带连接池，默认开启长连接复用。
但不是所有服务都支持 Keep-Alive，有些反向代理（比如 Nginx 默认配置）或老旧 API 网关会直接忽略 Connection: keep-alive 头，甚至主动断连。这时你用 Session 也白搭，连接还是秒断。
- 必须显式用
with requests.Session() as s:或手动调s.close()，否则连接池不释放，可能耗尽文件描述符 - 如果目标服务响应头没返回
Connection: keep-alive或含Connection: close，requests 会自动降级为短连，不报错也不提醒 - 高并发下连接池大小要调：
requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=20)，默认只有 10，容易卡住
urllib3 的 PoolManager 和 HTTPConnectionPool 到底管什么
requests 底层靠 urllib3，而 PoolManager 是顶层路由分发器，按 host:port 缓存 HTTPConnectionPool 实例。每个 pool 管一个 host 的连接复用，不是全局一把梭。
这意味着 https://api.example.com 和 https://upload.example.com 即使同域，也会走两个独立连接池——DNS 解析结果不同、端口不同、SSL 上下文不同，都会触发新 pool。
立即学习“Python免费学习笔记（深入）”；
萌次元商城是一个针对二次元的开源发卡系统。系统免费开源、界面美观、功能丰富。 （存在与第三方服务器连接的付费增值服务，但自身免费功能能够满足基本需求） 版权：遵循MIT协议从lizhipay处获得授权进行再分发 特色功能： 1.可以分发密钥，作为发卡网使用 2.可以关联快递单号，作为微商自建电商平台使用 3.支持多种支付方式，包括微信、支付宝、银联和国际
- 自定义
PoolManager时别漏掉maxsize和block=True，否则并发超限时直接抛MaxRetryError - pool 的
timeout是连接+读取总超时，和 requests 的timeout=(conn_timeout, read_timeout)不等价，混用容易误判 - 调试连接复用是否生效，看日志里有没有
Starting new HTTPS connection—— 复用时只打Resetting dropped connection或静默重用
短连接适合哪些场景，硬上长连接反而坏事
短连接不是缺陷，是设计选择。当请求间隔长、目标不稳定、或客户端生命周期极短（比如 AWS Lambda 单次执行），长连接反而浪费资源、拖慢冷启动、甚至因服务端 idle timeout 导致首字节延迟升高。
- 脚本类工具（如定时 sync 脚本）、CLI 工具、一次性爬虫，用
requests.get()更干净，不用操心 session 生命周期 - 调用 HTTP/1.0 服务或明确声明
Connection: close的接口，长连接无意义，还可能因复用已关闭 socket 报RemoteDisconnected - 某些云函数环境（如 Cloudflare Workers）根本不支持长连接，socket 在 handler 返回后强制销毁，强行用 Session 只会多一次无效 connect 尝试
HTTP/2 下长连接行为有啥不一样
requests 目前不原生支持 HTTP/2，得换 httpx 或 aiohttp。而 HTTP/2 的“长连接”本质是 multiplexing：单个 TCP 连接上并发跑多个 stream，不是简单复用 request-response 循环。
这时候连接池逻辑变了——httpx.Client() 的连接池按 (scheme, host, port, http_version) 四元组索引，HTTP/2 连接不会跟 HTTP/1.1 混用。而且 HTTP/2 的 server push、流控、优先级机制，会让“连接空闲是否该关”变得更复杂。
- 用
httpx时别只改http2=True，还得确认服务端真支持，否则 fallback 到 HTTP/1.1 且不报错 - HTTP/2 连接的 idle timeout 由服务端通过
SETTINGS_MAX_IDLE_TIME控制，客户端无法单方面延长，抓包看SETTINGS帧才能确认 - 某些中间件（如 Envoy）对 HTTP/2 长连接的 keepalive 心跳处理不一致，可能比 HTTP/1.1 更早断连，需要额外配
http2_keep_alive_interval
真正难的不是选长还是短，是看懂服务端的连接策略和中间件行为。很多问题表面是 Python 连接复用失效，实际是 Nginx 的 keepalive_timeout 设成 5 秒，或者 CDN 把 Connection 头给 strip 了。
