guzzle安装失败主因是php版本不匹配或composer源问题；guzzle 7要求php≥7.2、8要求≥7.4，国内建议换阿里云镜像并清缓存；类未找到需确认autoload引入和vendor完整性；guzzle 8默认抛异常，需设http_errors=>false才兼容7的行为。
Composer 安装 Guzzle 时提示 guzzlehttp/guzzle 找不到包？
不是包名写错了，就是 Composer 源或 PHP 版本不匹配。Guzzle 7+ 要求 PHP ≥ 7.2，Guzzle 8+ 要求 PHP ≥ 7.4；国内用户常因默认源慢或镜像过期导致安装失败。
- 确认 PHP 版本：
php -v，低于 7.4 就别硬上 Guzzle 8，改用composer require guzzlehttp/guzzle:^7.5 - 换阿里云镜像（临时）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清缓存再试：
composer clear-cache，再运行composer require guzzlehttp/guzzle - 如果项目已锁死
composer.json中的platform版本，检查是否有类似"php": "7.2"的限制，删掉或调高
require guzzlehttp/guzzle 后，new \GuzzleHttp\Client() 报类未找到？
自动加载没生效，常见于手动移动了 vendor、用了非标准 PSR-4 加载方式，或没引入 autoload。
- 确保执行了
composer install或composer require后生成了vendor/autoload.php - 在代码开头必须包含：
require 'vendor/autoload.php';（路径按实际调整） - 不要自己写
include或require_once到某个具体 Guzzle 类文件——它依赖完整 autoloader - 检查
vendor/guzzlehttp/guzzle/src/Client.php是否真实存在，不存在说明安装中断，删掉vendor和composer.lock重来
Guzzle 7 和 Guzzle 8 的 request() 用法差异大吗？
核心调用几乎一样，但错误处理和默认行为有关键变化：Guzzle 8 默认抛异常，Guzzle 7 默认返回响应对象；另外 request() 第二个参数从数组变成 array $options = []，但结构一致。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Guzzle 7 中
$response->getStatusCode()总能调，哪怕 HTTP 错误码也返回响应对象 - Guzzle 8 默认遇到 4xx/5xx 会直接抛
GuzzleHttp\Exception\ClientException或ServerException，需 try/catch - 想让 Guzzle 8 像 7 那样“不抛错”，加选项：
['http_errors' => false] - POST JSON 最简写法统一为：
$client->post('https://api.example.com', ['json' => ['key' => 'val']])，不用再手动json_encode+headers
为什么 composer require guzzlehttp/guzzle 装了一堆其他包？
这是正常依赖收敛，不是冗余。Guzzle 本身依赖 psr/http-client、psr/http-message、ralouphie/getallheaders 等接口规范和工具包，Composer 自动拉取兼容版本。
- 这些依赖体积小、无副作用，别手动删
vendor里它们——会导致Class not found - 如果你只想要轻量 HTTP 客户端，Guzzle 不是唯一选择；但若已选它，就接受这套依赖链
- 升级时注意
guzzlehttp/psr7大版本变更（如 1.x → 2.x）可能引发类型错误，尤其自定义中间件时
最常被跳过的其实是 vendor/autoload.php 的引入时机和 http_errors 开关——这两个点卡住的人，比 PHP 版本问题还多。
