hyperf3.1中guzzle连续请求会话失效，根本原因是未启用rfc 6265兼容的cookie jar；必须显式配置'cookies' => true，否则set-cookie被丢弃，导致后续请求401或重定向。
在Hyperf3.1中使用Guzzle发起连续HTTP请求时，若登录后无法保持会话，后续接口返回401或重定向到登录页，本质是Cookie未被正确持久化——不是服务端问题，而是客户端未启用符合RFC 6265标准的Cookie Jar机制。
确认Guzzle客户端已启用Cookie Jar
Hyperf默认不自动启用Cookie Jar，必须显式配置。仅靠ClientFactory::create()返回的客户端，默认不会存储或发送Cookie。
调用ClientFactory::create()时，必须传入'cookies' => true选项。
【不加此选项，所有Set-Cookie响应头都会被丢弃，后续请求永远“裸奔”】
代码示例：
$client = $this->clientFactory->create(['cookies' => true]);
验证Cookie是否真实写入Jar
执行一次登录请求后，立即检查Jar中是否存在有效Cookie：
获取客户端底层GuzzleHttp\Cookie\CookieJar实例：
$jar = $client->getConfig('cookies');
打印当前Jar中所有Cookie（注意：仅用于调试，勿在生产环境print_r）：
var_dump($jar->toArray());
若输出为空数组[]，说明登录接口未返回Set-Cookie头，或响应状态码非2xx导致Guzzle跳过Cookie解析——此时应先检查登录接口本身是否成功返回会话凭证。
手动注入Cookie（应急/测试场景）
当需要绕过登录流程直接复用已有Cookie时，可用以下方式注入：
方法一：构造单个Cookie对象并添加
$cookie = new \GuzzleHttp\Cookie\Cookie('PHPSESSID', 'abc123', '/', 'example.com', true, true);
$jar->setCookie($cookie);
方法二：批量导入原始Cookie字符串（如浏览器开发者工具复制的name=value; Path=/; Domain=example.com; HttpOnly）
使用\GuzzleHttp\Cookie\CookieJar::fromString()静态方法解析：
$jar = \GuzzleHttp\Cookie\CookieJar::fromString("PHPSESSID=abc123; Path=/; Domain=example.com; HttpOnly", 'https://example.com');
⚠️ 注意：传入的base URI必须与目标域名匹配，否则Domain校验失败，Cookie将被静默丢弃。
排查子域名Cookie共享失效
第一步：确认服务端下发的Cookie Domain字段是否以点开头（如.example.com）
第二步：检查客户端请求的目标URL Host是否属于该Domain范围（如api.example.com → 匹配.example.com，但example.com不匹配.api.example.com）
第三步：若服务端设置的是Domain=example.com（无前导点），则仅example.com主域可读取，www.example.com和api.example.com均不可见——这是浏览器和Guzzle共同遵守的RFC行为，无法绕过。
解决路径：联系后端将Cookie Domain改为.example.com，确保子域共享生效。
