Guzzle 安装失败主因是 PHP 版本过低（7.2.5+ 或 7.4+）或未启用 cURL 扩展；类找不到需手动引入 vendor/autoload.php；超时/空响应需显式设 timeout 和 http_errors；Guzzle 8 移除 json() 方法，须用 json_decode((string)$response->getBody(), true)。
composer require guzzlehttp/guzzle 装不上？先看 PHP 版本和扩展
Guzzle 7.x 要求 PHP ≥ 7.2.5，Guzzle 8.x 起要求 PHP ≥ 7.4 —— 如果你用的是 PHP 7.3 或更低，composer require guzzlehttp/guzzle 会直接报错“Your requirements could not be resolved”，而不是提示版本问题。
另外，Guzzle 默认依赖 cURL 扩展。如果没启用，装完也跑不起来，发请求时抛 GuzzleHttp\Exception\ConnectException，错误信息里带 “cURL error 1” 或 “could not resolve host”。
- 检查 PHP 版本：
php -v - 检查 cURL 是否启用：
php -m | grep curl - 若未启用，Ubuntu/Debian 上运行
sudo apt install php-curl，然后重启 Web 服务或 CLI 环境
require 后调用 GuzzleHttp\Client 报类找不到？自动加载没生效
装完没报错，但 new GuzzleHttp\Client() 时提示 “Class 'GuzzleHttp\Client' not found”，大概率是没引入 Composer 自动加载文件。
不是所有项目都默认包含 vendor/autoload.php —— 尤其是手写脚本、命令行工具或老项目中容易漏掉这步。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确保在使用 Guzzle 前已执行：
require 'vendor/autoload.php'; - 路径必须准确：如果脚本不在项目根目录，要用相对/绝对路径，比如
require __DIR__ . '/vendor/autoload.php'; - 别把
autoload.php和composer.json搞混 —— 后者只是配置，不负责加载
发 GET 请求时 timeout 或返回空？默认配置太激进
Guzzle 7+ 默认 timeout 是 0（不限时），但实际行为受底层 cURL 影响；而某些环境（如 Docker、共享主机）可能触发 DNS 解析超时或连接阻塞，表现像“卡住”或返回空响应。
更常见的是没显式设置 http_errors，导致 4xx/5xx 响应直接抛异常，你以为是没返回，其实是被截断了。
- 加基础超时和错误控制：
$client = new GuzzleHttp\Client([ 'timeout' => 10, 'http_errors' => false ]); - 检查响应状态：
$response->getStatusCode()，别只看$response->getBody()->getContents() - 调试时加
verify => false（仅开发）绕过 SSL 验证，排除证书问题
升级到 Guzzle 8 后 json() 方法失效？返回值变了
Guzzle 7 的 $response->json() 是个便捷方法，Guzzle 8 移除了它 —— 不是 bug，是故意精简 API。现在必须手动解码：
- 正确写法：
json_decode($response->getBody()->getContents(), true) - 或者用 PSR-7 兼容方式：
json_decode((string) $response->getBody(), true) - 注意：Guzzle 8 的
getBody()返回Psr\Http\Message\StreamInterface，不能直接 echo 或 json_decode，必须转成字符串 - 如果你用 Laravel，
Http::get(...)->json()是框架封装的，跟 Guzzle 原生无关
http_errors、verify、timeout 这三个参数——它们不写出来，就按“看似合理实则脆弱”的默认值跑。 
