复用 requests.Session 可显著提升 HTTP 性能，因避免重复 TCP/TLS 开销；requests.get() 默认不复用因每次新建临时 Session 并销毁连接池；正确做法是全局持有并调优 Session 实例。

直接复用 requests.Session 能显著降低 HTTP 请求开销，尤其在高频、多请求、带 Cookie 或认证的场景下——不复用的话，每次 requests.get() 都新建 TCP 连接、重走 TLS 握手、丢弃连接池，性能损失可能达 3–10 倍。

为什么单次 requests.get() 默认不复用连接

因为 requests.get() 内部每次都会创建一个临时 Session 实例，用完即弃。它的底层 HTTPAdapter 虽默认启用了连接池（pool_connections=10, pool_maxsize=10），但这个池子只在该 Session 生命周期内有效。一旦函数返回，Session 销毁，连接池连同其中的 keep-alive 连接一并关闭。

常见误判现象：
- 多次调用 requests.get(url) 仍看到大量 TIME_WAIT 状态连接
- 抓包发现每请求都重新 TCP SYN + TLS handshake
- curl -w "%{time_connect} %{time_starttransfer}\n" -s URL 显示 connect 时间波动大

Session 复用的正确写法与关键配置

必须手动创建并长期持有同一个 Session 对象，而非每次请求都 new 一个。同时建议显式调优连接池参数，尤其在并发或长周期任务中：

• 复用是跨请求、跨函数、甚至跨线程（需注意线程安全）的，Session 应作为模块级变量或依赖注入对象，避免局部创建
• session.mount('https://', requests.adapters.HTTPAdapter(pool_connections=20, pool_maxsize=20)) —— 不要只改 pool_maxsize，pool_connections 控制「对不同 host 的最大连接池数」，小了会导致跨域名请求抢池子
• 若服务端支持 HTTP/2，requests 当前（v2.31+）仍不原生支持；需换 httpx 或 urllib3>=2.0 + 手动配置 h2
• 超时必须设：不设 timeout 可能卡死整个 Session，建议统一用 session.request(method, url, timeout=(3, 7))（connect, read）

import requests
✅ 正确：全局复用，显式调优
session = requests.Session()
adapter = requests.adapters.HTTPAdapter(
pool_connections=50,
pool_maxsize=50,
max_retries=2
)
session.mount('http://', adapter)
session.mount('https://', adapter)
后续所有请求都走这个 session
resp1 = session.get('https://www./link/1eb09b1b87507b37457999d05d657ae6')
resp2 = session.post('https://www./link/5fdb81013e74b3bb0c0e0ce50249c0ca', json={'item': 'book'})

Cookie、认证头与 Session 状态的隐式绑定

Session 不只是连接复用容器，它自动管理 Cookies、默认携带 Authorization（如果设过 session.auth）、合并 headers。这点常被忽略，导致「复用了 Session 却没生效」：

• 登录后调用 session.post('/login', data=...)，后续请求自动带上服务端返回的 Set-Cookie，无需手动取 session.cookies
• session.headers.update({'User-Agent': 'myapp/1.0'}) 是持久的；但 requests.get(url, headers={...}) 会覆盖 Session 级 header，不是追加
• 若需按请求动态改 header（如不同 token），别用 session.headers，而是在 session.get(url, headers={...}) 中传参
• 跨子域名（如 a.example.com → b.example.com）默认不共享 Cookie，需手动设置 session.cookies.set(domain='.example.com')

Session 关闭与资源泄漏风险

Session 持有连接池和底层 urllib3.PoolManager，不显式关闭可能导致文件描述符耗尽、连接无法释放，尤其在短生命周期脚本或 serverless 环境中：

• 长期运行的服务（如 Flask 后端、爬虫主循环）可不关，靠进程退出回收
• 命令行工具、单元测试、Lambda 函数务必在退出前调用 session.close()
• with requests.Session() as s: 语法是安全的，但仅适用于单次流程；不能用于「创建一次、多次使用」的场景
• 调用 session.close() 后再发请求会抛 InvalidSchema 或连接异常，需确保无残留引用

真正容易被绕过的点是：连接池大小和超时策略必须匹配实际负载，而不是照搬示例数字；还有就是误以为「用了 Session 就万事大吉」，结果因 Cookie 域名不匹配或 header 覆盖导致状态丢失——这些都不会报错，只会静默失败。