Django Rest Framework中requests.session跨请求共享的最佳实践是什么

安全性判断 #

• 如果你的外部API调用是服务级别的统一身份（比如用固定API Key、服务端令牌，和Django的终端用户无关），使用全局静态Session不存在安全问题，本身也符合设计逻辑。
• 如果你的外部API调用关联终端用户身份（不同用户调用时需要携带用户专属的cookie、令牌），绝对不要用全局静态Session：requests.Session会自动持久化请求返回的Cookie、Authorization等身份头，会出现不同用户身份串号、权限泄露的严重安全问题。
• 额外注意：requests.Session不是进程安全也不是线程安全的，如果你的Django是多进程/多线程部署，不要跨进程/跨线程共享同一个Session实例，否则会出现偶发的连接异常、数据错乱问题。

Session 刷新的合理判断指标 #

不需要无理由频繁刷新Session，以下几个是经过生产验证的触发条件：

• 请求抛出连接层面的异常时：比如ConnectionResetError、SSL握手异常、连接超时、代理错误，直接刷新Session后重试1次即可。
• 外部API返回401/403状态码时：先排除业务逻辑本身的权限问题，如果是会话过期导致的认证失败，刷新Session后重试。
• 固定阈值触发：可以设置两个兜底刷新规则，避免长时间复用出现未知问题：
  • 单个Session累计处理请求满100~500次（可根据外部API的连接存活配置调整）主动刷新
  • 单个Session初始化超过30分钟~1小时主动刷新
• 如果外部API有明确的会话有效期说明，直接按照官方要求的有效期刷新即可。

全局Session是不是不好的方案 #

你当前的场景是优化TCP、SSL握手的重复耗时，用Session复用连接是完全合理的方案，本身没有问题，只要规避前面提到的安全、进程线程兼容问题即可。
如果全局单Session不匹配你的业务场景，也可以用更灵活的替代方案：

• 针对服务级别调用的场景，可以给Session配置更大的连接池参数，适配多线程请求，比全局单Session的可用性更高，示例配置如下：

import requests

# 进程内唯一的Session实例，不要跨进程共享
service_session = requests.Session()
# 配置连接池，适配多线程并发请求
service_session.mount(
    "https://",
    requests.adapters.HTTPAdapter(
        pool_connections=10,  # 不同域名的连接池数量
        pool_maxsize=30,      # 单个域名的最大连接数，可根据并发量调整
        max_retries=2         # 连接错误时的自动重试次数
    )
)

• 如果是用户级别调用的场景，可以给每个用户单独维护Session，或者直接在每次请求时手动带身份参数，不依赖Session持久化身份，同样可以通过配置连接池复用TCP、SSL连接，既保证安全又能拿到性能收益。

内容的提问来源于stack exchange，提问作者ye_olde_csharp_programmer