cookie认证与config认证本质不兼容，必须为每类认证创建独立Session或用shell分支隔离curl参数，否则凭证会覆盖或静默失效。
多个服务器需要不同认证方式时，config 和 cookie 不能混用
直接说结论：cookie 认证和 config 认证（如 token、basic auth）本质不兼容，强行混合会导致某一方被覆盖或静默失效。常见于用 requests.session() 或 curl 管理多主机请求时，误以为能“分别配置”。
根本原因是：HTTP 客户端通常只维护一套默认凭证策略。比如 requests 的 Session 对象全局共享 auth 和 cookies，没有“按 host 分发”的内置机制；curl 的 --cookie 和 -u 也互斥——后者会覆盖前者发送的 Cookie 头。
- 不要在同一个
Session实例里先session.cookies.set(...)再设session.auth = (...)，后者会让前者的 Cookie 不再随请求发出 - 不要对同一
curl命令同时加--cookie和-u，-u会触发Authorization头并抑制Cookie头 - 若服务端要求 cookie 登录（如网页表单跳转后生成 sessionid），就别试图用 config 模式替代；反之，若 API 明确要求
Authorization: Bearer xxx，硬塞 cookie 会被忽略
requests 中为不同域名隔离认证：必须用独立 Session
唯一可靠做法是为每类认证方式创建专属 Session 实例，并绑定到对应域名。不是“配置切换”，而是“实例隔离”。
示例场景：调 api.example.com 用 token，调 admin.internal 用登录态 Cookie。
- 创建两个
Session：token_session = requests.Session()和cookie_session = requests.Session() - 给
token_session设token_session.headers['Authorization'] = 'Bearer xxx'（不是auth=...） - 给
cookie_session手动注入 cookie：cookie_session.cookies.set('sessionid', 'abc123', domain='admin.internal') - 后续请求严格按域名选 Session：
token_session.get('https://api.example.com/v1/users')，cookie_session.get('https://admin.internal/dashboard')
curl 脚本中按目标服务器切换认证：用变量 + 条件分支
curl 本身不支持运行时动态切认证，只能靠 shell 控制流实现“逻辑分离”。关键不是参数拼接，而是避免把所有选项堆进一个命令。
错误写法：curl -u user:pass --cookie "sid=xxx" https://host/ → 两者冲突，且 cookie 域名未限定，可能泄露。
- 用变量存不同认证参数：
TOKEN_AUTH="-H 'Authorization: Bearer abc'"，COOKIE_AUTH="--cookie 'sessionid=def; Domain=admin.internal'" - 用
case或if匹配 URL 域名，只传入对应参数：curl $TOKEN_AUTH https://api.example.com/... - 务必显式指定
Domain=在 cookie 字符串里，否则curl可能不发送该 cookie 到目标 host - 不要依赖
~/.netrc混合管理——它只支持 basic auth，无法注入 cookie
容易被忽略的坑：Cookie 域名匹配与 HTTPS 严格性
即使 Session 或 curl 配置正确，Cookie 仍可能不发出——问题常出在域名细节上。
-
cookie_session.cookies.set('sid', 'x', domain='.example.com')不会匹配api.example.com，除非显式写成domain='example.com'或domain='.example.com'（注意开头的点） - 如果目标是
https://admin.internal，但本地 hosts 把它指向127.0.0.1，部分客户端（尤其浏览器环境或某些 HTTP 库）会因 SNI 或证书校验拒绝发送 Cookie - 使用
httpx替代requests时，其CookieJar默认更严格：不自动处理Set-Cookie的Domain缩写，必须完全匹配
复杂点在于：认证方式不是配置项开关，而是请求发起时的上下文快照。一旦写错域名、协议或实例复用，问题往往表现为“偶尔失败”或“只对某个 host 有效”，排查时容易绕远路。
