requests.session() 是处理 cookie 的默认且正确选择，它自动管理 cookie 生命周期，无需手动传递或担心丢失，适用于绝大多数接口自动化场景。
requests.Session() 是处理 Cookie 的默认选择，不是可选项
绝大多数接口自动化场景里，requests.Session() 就是正确答案。它自动管理 Cookie 生命周期：登录响应里的 Set-Cookie 会被提取、存储，并在后续所有请求中自动携带。不用手动传 cookies=...，也不用担心跨请求丢失。
常见错误现象包括：
- 用普通
requests.get()发送登录请求后，再用另一个requests.get()访问需登录接口，返回 401 或重定向到登录页 - 手动提取
response.cookies后传给下个请求，但漏了 domain/path/secure 等属性，导致服务端不认
实操建议：
- 整个测试会话只初始化一个
session = requests.Session()实例，复用到底 - 登录成功后立刻用
session.get('/dashboard')验证是否真正维持了状态，别只看登录接口返回 200 - 如果服务端设置了
HttpOnly或Securecookie，Session仍能正常处理，无需额外配置
pytest fixture 中封装 Session 要注意作用域和复用边界
把 Session 放进 fixture 里很常见，但容易踩的坑是作用域设错。比如设成 scope="session"，多个测试用例共用一个 session，一旦某个用例触发了登出或 token 过期，后续全挂。
使用场景决定作用域：
-
scope="function"：每个测试函数独享 session，适合需要隔离状态的用例（如并发登录、权限切换） -
scope="class"：同一测试类内共享 session，适合一组有状态依赖的接口（如「登录 → 创建订单 → 查询订单」） -
scope="module"：慎用；仅当模块内所有测试都基于同一登录态且无状态污染风险时才考虑
示例代码片段（function 级）：
@pytest.fixture(scope="function")
def logged_in_session():
s = requests.Session()
s.post("https://api.example.com/login", json={"user": "test", "pwd": "123"})
return s
注意：不要在 fixture 里做 yield s 再加 s.close() —— Session 没有必须 close 的资源释放逻辑，反而可能干扰连接池复用。
绕过登录时直接注入 Cookie，得还原完整 cookie-attribute
当验证码无法自动识别、或登录接口被限流，常需手动注入已知有效的 Cookie。这时不能只塞 {"key": "value"} 字典，否则服务端校验失败。
关键点在于还原原始 Set-Cookie 头里的属性：
- domain 必须匹配（比如
.example.com，不是www.example.com） - path 通常为
/，但有些系统设为/api/，路径不匹配则不发送 - secure 和 httponly 不影响 requests 注入，但 domain/path 错误会导致 Cookie 被静默丢弃
正确做法是用 RequestsCookieJar 构建：
cj = requests.cookies.RequestsCookieJar()
cj.set("JSESSIONID", "abc123", domain=".example.com", path="/", secure=True)
session.cookies.update(cj)
验证是否生效：调用 session.get("/api/user") 后检查响应头是否有 Set-Cookie 被更新，或打印 session.cookies 看是否包含刚 set 的条目。
Session 对象本身不保存 headers，但可以被污染
requests.Session() 默认不带任何 headers，但很多人会在登录后执行 session.headers.update({"Authorization": "Bearer xxx"})。这看似方便，实则埋雷。
问题在于：session.headers 是全局生效的。如果某次请求需要临时覆盖 Authorization（比如测试不同角色权限），用 session.get(url, headers={...}) 会和 session 级 headers 合并，可能造成字段冲突或重复。
更稳妥的方式：
- 只用
session.cookies管理会话态，认证信息统一走 Cookie - 若必须用 token，改用
session.auth（适合 Basic Auth）或显式传headers到每个请求 - 避免在 fixture 初始化阶段就往
session.headers里写死值，除非整个测试套件确实共用同一认证方式
复杂点往往不在“怎么加 Cookie”，而在于“什么时候该清掉它”。比如一个测试类里前几个用例用了 admin 登录，最后一个用例要测 guest 权限 —— 此时得主动调用 session.cookies.clear()，而不是依赖 fixture 重建。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
