requests Session 怎么创建与关闭context manager 用法与 Cookie、auth、headers 的会话级持久化【免费下载链接】requestsA simple, yet elegant, HTTP library.项目地址: https://gitcode.com/GitHub_Trending/re/requests如果你的程序要对同一个服务连续发起多次请求每次都调用requests.get()这种顶层函数就会丢失两样东西登录态Cookie不会在请求之间延续底层 TCP 连接也不会复用。requests 库为此提供了Session对象它允许把 Cookie、认证、请求头、代理等参数持久化在多次请求之间同时基于urllib3的连接池复用同主机的 TCP 连接。本文基于仓库文档 docs/user/advanced.rst、docs/user/authentication.rst、docs/user/quickstart.rst 和源码 src/requests/sessions.py 说明如何创建一个 Session、如何用 context manager 或close()可靠关闭它以及 Cookie、auth、headers 三类会话级状态的设置方式与验证方法。前提条件按 docs/user/install.rst 完成安装。$ python -m pip install requests创建 Sessionrequests.Session()创建方式就是实例化Session类。Session对象拥有主 API 的全部方法get、post、put、delete等可以直接把文档中的requests.get(...)换成s.get(...)import requests s requests.Session() s.get(https://httpbin.org/get) # Response [200]注意两点不要使用旧的小写工厂函数requests.session()。源码注释明确它自 1.0.0 起已弃用deprecated新代码应直接使用Session类创建会话见 src/requests/sessions.py。Session 创建时即初始化了一批会话级属性后续请求默认继承这些值见 src/requests/sessions.pyheaders为 requests 默认请求头、auth为None、cookies为空 CookieJar、verify为True、max_redirects为DEFAULT_REDIRECT_LIMIT30、trust_env为True。同一 Session 内的 keep-alive 是完全自动的会话内发出的请求会自动复用对应连接。但连接只有在响应 body 数据被完整读取后才释放回连接池所以要么保持默认streamFalse要么读取Response.content。关闭 Sessioncontext manager 与close()Session 内部为 HTTP 和 HTTPS 各挂载一个HTTPAdapter关闭 Session 实质是关闭这些 adapter 持有的连接。有两种关闭方式。方式一context manager推荐with requests.Session() as s: s.get(https://httpbin.org/cookies/set/sessioncookie/123456789)官方文档docs/user/advanced.rst给出的保证是只要退出with块session 就一定被关闭——即使块内发生了未处理的异常。对应实现是Session.__exit__直接调用self.close()而close()会遍历并关闭所有 adaptersrc/requests/sessions.py、src/requests/sessions.py。如果你的请求使用了streamTrue且只读取了部分 bodyRequests 无法把连接归还连接池。此时同样要在with语句内完成请求确保响应被处理或关闭with requests.get(https://httpbin.org/get, streamTrue) as r: # Do things with the response here.方式二手动调用close()s requests.Session() # ... 若干请求 ... s.close()适合 Session 生命周期跨越多个函数、无法整体包在with块里的场景。只要不调用close()Session 也不会自动关闭连接池就一直占用着。Cookie 的会话级持久化这是 Session 最核心的用途通过 Session 收到的 Cookie 会自动进入它的 CookieJar并在之后的请求中自动带上。文档示例docs/user/advanced.rsts requests.Session() s.get(https://httpbin.org/cookies/set/sessioncookie/123456789) r s.get(https://httpbin.org/cookies) print(r.text) # {cookies: {sessioncookie: 123456789}}第一个请求由服务器设置 Cookie第二个请求自动携带它httpbin.org/cookies端点会把当前请求携带的 Cookie 回显为 JSON。上面的输出是文档示例用于说明持久化生效的判断方式。方法级 Cookie 不会持久化这是最容易踩的坑。同一个 Session 中把 Cookie 作为方法参数传入只对当次请求有效s requests.Session() r s.get(https://httpbin.org/cookies, cookies{from-my: browser}) print(r.text) # {cookies: {from-my: browser}} r s.get(https://httpbin.org/cookies) print(r.text) # {cookies: {}}第二次请求返回空 Cookie文档示例输出说明cookies参数并未写入会话。若想让 Cookie 在整个会话期间生效应写入会话的 CookieJar而不是每次作为参数传入。手动向 Session 添加 Cookie不经过服务器 Set-Cookie、想直接预置 Cookie 时用文档列出的 Cookie 工具函数docs/api.rst 的 Cookies 一节操作Session.cookies属性from requests.utils import add_dict_to_cookiejar s requests.Session() # 把 key/value 字典写入会话的 CookieJar之后每个请求都会携带 add_dict_to_cookiejar(s.cookies, dict(session_cookie123456789))add_dict_to_cookiejar(cj, cookie_dict)返回被更新的 CookieJar见 src/requests/utils.py。反向操作是dict_from_cookiejar(cj)把 CookieJar 转成普通字典适合排查当前会话到底持有哪些 Cookie。也可以用requests.cookies.cookiejar_from_dict()构造 CookieJar 后再赋给s.cookies。验证方式与上一节相同请求/cookies端点r.text中出现你预置的 Cookie 即表示写入成功。auth 与 headers 的会话级持久化把认证和公共请求头设置到 Session 属性上该 Session 的每个请求都会带上s requests.Session() s.auth (user, pass) s.headers.update({x-test: true}) # both x-test and x-test2 are sent s.get(https://httpbin.org/headers, headers{x-test2: true})上面的s.auth (user, pass)是 HTTP Basic Auth 的元组简写效果等价于requests.auth.HTTPBasicAuth(user, pass)docs/user/authentication.rst 中两者均请求https://httpbin.org/basic-auth/user/pass并返回Response [200]。需要 Digest Auth 或其他机制时同样可以把对应对象赋给s.auth。会话级与方法级参数的合并规则docs/user/advanced.rst 明确了合并语义写多请求代码前建议记住三条传给请求方法的字典参数如headers会与 Session 级值合并而不是替换方法级参数覆盖 Session 级同键参数所以示例中x-test会话级和x-test2方法级都会发送想省略某个会话级的 key在方法级参数中把该 key 的值设为None它会被自动剔除。判断合并是否生效可以请求httpbin.org/headers该端点把收到的请求头原样回显检查响应中是否同时包含会话级与方法级的头。常见限制哪些状态不会随 Session 生效Prepared Request 流程会丢失会话状态。如果你手动构造Request再调用req.prepare()得到的PreparedRequest不会带上 Session 级的 Cookie 等状态。要用会话状态请改用Session.prepare_request(req)from requests import Request, Session s Session() req Request(GET, url, datadata, headersheaders) prepped s.prepare_request(req) resp s.send(prepped)此外trust_env为默认值True时若请求未显式提供 authSession 会尝试从用户的 netrc 文件~/.netrc、~/_netrc或NETRC环境变量指定的路径取凭据并以 HTTP Basic Auth 发送。要禁用 netrc 文件将s.trust_env Falsedocs/user/authentication.rst。小结与验证清单一次完整的会话生命周期可以归纳为requests.Session()创建 → 设置s.cookies/s.auth/s.headers等会话级属性 → 用s.get(...)等方法发请求 → 用with块退出或s.close()关闭。逐项验证Cookie 持久化请求/cookies端点r.text回显会话中设置的 Cookie文档示例输出为{cookies: {sessioncookie: 123456789}}headers/auth 持久化/headers端点回显的头部中包含会话级设置的键且方法级同键参数覆盖成功关闭行为with块内即使抛出异常退出后 Session 也会被关闭连接池被释放。需要更多会话属性proxies、verify、max_redirects等的完整说明参考 docs/api.rst 中 Session 的 API 文档:ref:sessionapi。【免费下载链接】requestsA simple, yet elegant, HTTP library.项目地址: https://gitcode.com/GitHub_Trending/re/requests创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 requests Session 怎么创建与关闭？context manager 用法与 Cookie、auth、headers 的会话级持久化
requests Session 怎么创建与关闭context manager 用法与 Cookie、auth、headers 的会话级持久化【免费下载链接】requestsA simple, yet elegant, HTTP library.项目地址: https://gitcode.com/GitHub_Trending/re/requests如果你的程序要对同一个服务连续发起多次请求每次都调用requests.get()这种顶层函数就会丢失两样东西登录态Cookie不会在请求之间延续底层 TCP 连接也不会复用。requests 库为此提供了Session对象它允许把 Cookie、认证、请求头、代理等参数持久化在多次请求之间同时基于urllib3的连接池复用同主机的 TCP 连接。本文基于仓库文档 docs/user/advanced.rst、docs/user/authentication.rst、docs/user/quickstart.rst 和源码 src/requests/sessions.py 说明如何创建一个 Session、如何用 context manager 或close()可靠关闭它以及 Cookie、auth、headers 三类会话级状态的设置方式与验证方法。前提条件按 docs/user/install.rst 完成安装。$ python -m pip install requests创建 Sessionrequests.Session()创建方式就是实例化Session类。Session对象拥有主 API 的全部方法get、post、put、delete等可以直接把文档中的requests.get(...)换成s.get(...)import requests s requests.Session() s.get(https://httpbin.org/get) # Response [200]注意两点不要使用旧的小写工厂函数requests.session()。源码注释明确它自 1.0.0 起已弃用deprecated新代码应直接使用Session类创建会话见 src/requests/sessions.py。Session 创建时即初始化了一批会话级属性后续请求默认继承这些值见 src/requests/sessions.pyheaders为 requests 默认请求头、auth为None、cookies为空 CookieJar、verify为True、max_redirects为DEFAULT_REDIRECT_LIMIT30、trust_env为True。同一 Session 内的 keep-alive 是完全自动的会话内发出的请求会自动复用对应连接。但连接只有在响应 body 数据被完整读取后才释放回连接池所以要么保持默认streamFalse要么读取Response.content。关闭 Sessioncontext manager 与close()Session 内部为 HTTP 和 HTTPS 各挂载一个HTTPAdapter关闭 Session 实质是关闭这些 adapter 持有的连接。有两种关闭方式。方式一context manager推荐with requests.Session() as s: s.get(https://httpbin.org/cookies/set/sessioncookie/123456789)官方文档docs/user/advanced.rst给出的保证是只要退出with块session 就一定被关闭——即使块内发生了未处理的异常。对应实现是Session.__exit__直接调用self.close()而close()会遍历并关闭所有 adaptersrc/requests/sessions.py、src/requests/sessions.py。如果你的请求使用了streamTrue且只读取了部分 bodyRequests 无法把连接归还连接池。此时同样要在with语句内完成请求确保响应被处理或关闭with requests.get(https://httpbin.org/get, streamTrue) as r: # Do things with the response here.方式二手动调用close()s requests.Session() # ... 若干请求 ... s.close()适合 Session 生命周期跨越多个函数、无法整体包在with块里的场景。只要不调用close()Session 也不会自动关闭连接池就一直占用着。Cookie 的会话级持久化这是 Session 最核心的用途通过 Session 收到的 Cookie 会自动进入它的 CookieJar并在之后的请求中自动带上。文档示例docs/user/advanced.rsts requests.Session() s.get(https://httpbin.org/cookies/set/sessioncookie/123456789) r s.get(https://httpbin.org/cookies) print(r.text) # {cookies: {sessioncookie: 123456789}}第一个请求由服务器设置 Cookie第二个请求自动携带它httpbin.org/cookies端点会把当前请求携带的 Cookie 回显为 JSON。上面的输出是文档示例用于说明持久化生效的判断方式。方法级 Cookie 不会持久化这是最容易踩的坑。同一个 Session 中把 Cookie 作为方法参数传入只对当次请求有效s requests.Session() r s.get(https://httpbin.org/cookies, cookies{from-my: browser}) print(r.text) # {cookies: {from-my: browser}} r s.get(https://httpbin.org/cookies) print(r.text) # {cookies: {}}第二次请求返回空 Cookie文档示例输出说明cookies参数并未写入会话。若想让 Cookie 在整个会话期间生效应写入会话的 CookieJar而不是每次作为参数传入。手动向 Session 添加 Cookie不经过服务器 Set-Cookie、想直接预置 Cookie 时用文档列出的 Cookie 工具函数docs/api.rst 的 Cookies 一节操作Session.cookies属性from requests.utils import add_dict_to_cookiejar s requests.Session() # 把 key/value 字典写入会话的 CookieJar之后每个请求都会携带 add_dict_to_cookiejar(s.cookies, dict(session_cookie123456789))add_dict_to_cookiejar(cj, cookie_dict)返回被更新的 CookieJar见 src/requests/utils.py。反向操作是dict_from_cookiejar(cj)把 CookieJar 转成普通字典适合排查当前会话到底持有哪些 Cookie。也可以用requests.cookies.cookiejar_from_dict()构造 CookieJar 后再赋给s.cookies。验证方式与上一节相同请求/cookies端点r.text中出现你预置的 Cookie 即表示写入成功。auth 与 headers 的会话级持久化把认证和公共请求头设置到 Session 属性上该 Session 的每个请求都会带上s requests.Session() s.auth (user, pass) s.headers.update({x-test: true}) # both x-test and x-test2 are sent s.get(https://httpbin.org/headers, headers{x-test2: true})上面的s.auth (user, pass)是 HTTP Basic Auth 的元组简写效果等价于requests.auth.HTTPBasicAuth(user, pass)docs/user/authentication.rst 中两者均请求https://httpbin.org/basic-auth/user/pass并返回Response [200]。需要 Digest Auth 或其他机制时同样可以把对应对象赋给s.auth。会话级与方法级参数的合并规则docs/user/advanced.rst 明确了合并语义写多请求代码前建议记住三条传给请求方法的字典参数如headers会与 Session 级值合并而不是替换方法级参数覆盖 Session 级同键参数所以示例中x-test会话级和x-test2方法级都会发送想省略某个会话级的 key在方法级参数中把该 key 的值设为None它会被自动剔除。判断合并是否生效可以请求httpbin.org/headers该端点把收到的请求头原样回显检查响应中是否同时包含会话级与方法级的头。常见限制哪些状态不会随 Session 生效Prepared Request 流程会丢失会话状态。如果你手动构造Request再调用req.prepare()得到的PreparedRequest不会带上 Session 级的 Cookie 等状态。要用会话状态请改用Session.prepare_request(req)from requests import Request, Session s Session() req Request(GET, url, datadata, headersheaders) prepped s.prepare_request(req) resp s.send(prepped)此外trust_env为默认值True时若请求未显式提供 authSession 会尝试从用户的 netrc 文件~/.netrc、~/_netrc或NETRC环境变量指定的路径取凭据并以 HTTP Basic Auth 发送。要禁用 netrc 文件将s.trust_env Falsedocs/user/authentication.rst。小结与验证清单一次完整的会话生命周期可以归纳为requests.Session()创建 → 设置s.cookies/s.auth/s.headers等会话级属性 → 用s.get(...)等方法发请求 → 用with块退出或s.close()关闭。逐项验证Cookie 持久化请求/cookies端点r.text回显会话中设置的 Cookie文档示例输出为{cookies: {sessioncookie: 123456789}}headers/auth 持久化/headers端点回显的头部中包含会话级设置的键且方法级同键参数覆盖成功关闭行为with块内即使抛出异常退出后 Session 也会被关闭连接池被释放。需要更多会话属性proxies、verify、max_redirects等的完整说明参考 docs/api.rst 中 Session 的 API 文档:ref:sessionapi。【免费下载链接】requestsA simple, yet elegant, HTTP library.项目地址: https://gitcode.com/GitHub_Trending/re/requests创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考