Requests 只在 PyCharm Behave 报 CookieJar 错误，检查重复导入

同一套 Behave 测试在终端正常，放进 PyCharm 的 Behave runner 却在 Session.prepare_request() 报 ValueError: You can only merge into CookieJar。如果使用 Requests 2.34.0 及之后版本，且应用没有自己替换 CookieJar，先检查运行器是否重复加载了标准库模块。

一个明确环境是 Requests 2.34.0、Behave 1.3.3、Python 3.13.1 和 PyCharm 2026.1.5。出错进程中，两个类都显示为 http.cookiejar.CookieJar，但对象身份不同；同一类名和同一文件路径，不足以证明它们是同一个 Python 类对象。

在失败进程里比较类对象

以下片段不发送 HTTP 请求，也不读取 Cookie 值。应放在已经失败的同一解释器与运行器中观察：

import requests.cookies as rc

jar = rc.RequestsCookieJar()
base = type(jar).__mro__[1]
checked = rc.cookielib.CookieJar

print(base is checked)
print(isinstance(jar, checked))
print(base.__module__, checked.__module__)

cookielib 是 Requests 的内部兼容引用，这里只作针对版本的诊断，不能把它作为业务依赖接口。若前两项为假，而模块名都指向 http.cookiejar，再结合运行器导入记录定位重复加载。若前两项正常，应继续检查传给 merge_cookies() 的实际对象类型，不能直接认定 IDE 有错。

Requests 2.34.2 的正式实现仍有两条引用：RequestsCookieJar 直接继承导入的 CookieJar，部分类型检查使用兼容模块保存的 cookielib.CookieJar。标准库模块被重新加载时，旧引用与新类可能分离，导致看似属于 CookieJar 的对象过不了检查。

保持同一环境，先绕开异常运行入口

已经确认只有 PyCharm Behave runner 失败时，可以用同一虚拟环境的命令行 Behave 入口运行原来的测试。对照前先确认解释器、工作目录、环境变量和测试选择一致；另一个终端恰好用了不同依赖，不能作为运行器差异的证据。

这种处理绕开的是重复导入路径，不是修复 Requests 的 Cookie 域匹配。不要把 CookieJar 转成普通字典再塞回去，或删除类型检查；这些做法可能丢掉域、路径和过期等规则。已有会话 Cookie 也不需要为了这项类身份错误全部清空。

后续更新 IDE 或相关运行插件时，复核实际安装版本是否解决相同的重复导入行为。恢复测试入口后，应重新启动进程，避免继续使用旧类引用；不建议靠删除 sys.modules 条目、反复 reload 或给库里的类手动赋值拼接状态。

验收包括同一入口完成请求准备、原来的会话规则保持，以及实际测试业务通过。CookieJar 类型检查通过只证明对象类型一致，不证明登录成功。若终端和 IDE 均报错，应保留新的完整堆栈，回到对象来源和依赖环境检查，不把这个局部案例扩成所有 CookieJar 错误的答案。