session级fixture共享token易致401或ScopeMismatch错误，主因是生命周期不匹配：token与依赖对象（如function级request_util）作用域冲突、token过期、header被覆盖；应确保token与client同级或解耦，显式注入而非自动设置。
session 级 fixture 能共享 token，但极易因状态耦合导致 401 或 ScopeMismatch 错误——关键不在“能不能用”，而在“怎么隔离依赖”。
为什么 scope="session" 的 token fixture 会出错
常见错误不是 token 拿不到，而是拿得到、用不了：测试运行中途 token 过期、被其他用例改写 header、或 fixture 依赖了 function 级对象（比如带实例状态的 RequestUtil）。根本原因是 session 级 fixture 创建一次、复用全程，但它引用的对象生命周期若不匹配，就会污染。
典型报错：ScopeMismatch: You tried to access the function scoped fixture request_util with a session scoped request object
- auth_token 是
session级，但内部调用了request_util（若设为function级）→ 直接报错 - 多个测试并发执行时，
requests.Session实例被反复复用，header 中的Authorization可能被覆盖或残留旧值 - token 本身有有效期，session 级 fixture 不做刷新逻辑，后半程用例必然 401
正确写法：token 和 client 必须同级或解耦
要让 scope="session" 安全落地，必须保证 token 获取过程和后续请求所用 client 在生命周期上自洽。两种可靠路径：
立即学习“Python免费学习笔记（深入）”；
- 用原生
requests.Session+ 手动注入 token，client 和 token 同为session级，且 client 不封装可变状态（如不把 token 存在实例属性里） - 把 token 获取逻辑完全抽离，用
@pytest.fixture(scope="session")单独返回纯字符串 token；所有请求 client（function或session级）都只读取它，不修改它
示例（安全版）：
@pytest.fixture(scope="session")
def global_token():
login_url = "https://api.example.com/auth/login"
resp = requests.post(login_url, json={"username": "test", "password": "test"})
assert resp.status_code == 200
return resp.json()["data"]["token"]
<p>@pytest.fixture(scope="session")
def api_client(global_token):</p><h1>注意：这里不修改 client 实例的 headers，每次请求再动态加</h1><pre class="brush:php;toolbar:false;">session = requests.Session()
# 不在这里 set header！留到每个请求时注入
return sessiondef test_user_info(api_client, global_token): headers = {"Authorization": f"Bearer {global_token}"} resp = api_client.get("https://www.php.cn/link/d3edfaac7b134307771e928cc3293131", headers=headers) assert resp.status_code == 200
什么时候该放弃 session 改用 module 或缓存
如果你的 token 有效期短于整个测试 session（比如 30 分钟），或者测试套件运行时间不可控（CI 环境可能超时），硬撑 session 就是给自己埋雷。更务实的做法：
- 降级为
scope="module"：一个测试文件内只登录一次，平衡复用与隔离 - 加本地缓存（如
pickle或json文件）：先查缓存中 token 是否有效（可比对时间戳），无效再重登，避免每次重跑都触发登录接口 - 用 Redis 缓存 + 过期时间：适合多进程/分布式测试，但引入外部依赖，本地调试成本上升
缓存判断逻辑不能只看文件是否存在，必须验证 token 是否仍在有效期——很多团队漏掉这步，结果缓存了个过期 token，所有用例静默失败。
自动注入 header 的陷阱：别在 fixture 里偷偷改 Session 实例
有人喜欢在 api_client fixture 里直接 session.headers.update(...)，以为这样后续请求就自动带 token。问题在于：
- 如果多个测试共用这个 session 实例，header 会被后一个测试覆盖前一个的 token
- 如果某个测试手动传了
headers参数，requests默认会忽略session.headers，导致鉴权失效却难以排查 - session 实例一旦被污染（比如某次请求设置了错误的
Content-Type），后续所有请求都继承这个错误
真正稳妥的方式是：fixture 只提供干净的 Session 实例，token 作为独立 fixture 注入，请求时显式组合 —— 把“谁负责什么”划清楚，比省几行代码重要得多。
