Composer 依赖冲突根源在于多包对 Guzzle 提出互斥版本要求，需用 composer why-not 定位封杀链、show --tree 查真实路径、--no-dev 验证测试工具干扰，并通过放宽私有包约束或降级目标包解决。
composer why guzzlehttp/guzzle 显示多个版本路径，但项目只用一个
这说明 Guzzle 被不同层级的包拉进来，且各自锁定了不兼容的版本——比如 laravel/framework 拉了 guzzlehttp/guzzle ^7.4，而某个测试工具（如 phpunit/phpunit）通过 symfony/http-client 间接依赖了 ^6.5。PHP 只能加载一个 guzzlehttp/guzzle，运行时如果某段代码调用了 v6 的 HandlerStack::push()，而实际加载的是 v7，就会抛出 Call to undefined method 或 cURL 相关异常（如 curl_setopt_array(): CURLOPT_HEADERFUNCTION is not supported）。
-
composer why guzzlehttp/guzzle输出里若出现require-dev中的包（如orchestra/testbench、mockery/mockery），优先加--no-dev验证：运行composer update --no-dev --dry-run -v看是否还报错 - 如果去掉 dev 包后冲突消失，说明问题不在主业务逻辑，而是测试工具链拖累了版本选择
- 别直接删
require-dev，先查它依赖的 Guzzle 版本：运行composer show --tree phpunit/phpunit | grep guzzle
composer why-not guzzlehttp/guzzle:^7.5 报 “because your-project requires guzzlehttp/guzzle ^6.5”
这个提示里的 your-project 往往不是你手动写的 "guzzlehttp/guzzle": "^6.5"，而是某个私有 SDK 或老版本组件在 composer.json 里硬编码了窄约束。例如："acme/payment-sdk": "dev-main" 内部写了 "guzzlehttp/guzzle": "6.5.4"，导致 Composer 无法升到 7.x。
- 运行
composer why-not guzzlehttp/guzzle:^7.5，看输出最后一行是否指向你的私有包名（如acme/payment-sdk） - 如果是，进该 SDK 仓库，改它的
composer.json：把"guzzlehttp/guzzle": "6.5.4"改成"guzzlehttp/guzzle": "^6.5 || ^7.0"，前提是 SDK 代码真能兼容两套 Client API - 若 SDK 不可控，临时方案是降级目标包：比如你想装
laravel/sanctum:^3.0，但它要求 Guzzle ^7.2，那就改用laravel/sanctum:^2.15（支持 Guzzle ^6.5）
composer show --tree guzzlehttp/guzzle 显示两个不同版本被同时锁定
这是典型的“隐式多版本冲突”——Composer 实际只装了一个版本，但 composer.lock 里记录了多个路径指向不同版本，说明之前执行过不干净的 composer update 或混用了 --with-all-dependencies。此时 vendor/ 下的 Guzzle 文件可能残缺，autoload 机制会随机加载某一层的类，引发 cURL 行为不一致（比如超时设置失效、header 处理错乱）。
- 运行
composer show guzzlehttp/guzzle确认当前实际安装的版本（注意末尾的(locked to X.Y.Z)） - 如果
show和show --tree显示的版本不一致，说明composer.lock已损坏，必须重建：删掉vendor/和composer.lock，再跑composer install - 别用
composer update guzzlehttp/guzzle单点升级——它可能只更新顶层引用，而忽略间接依赖锁死的旧版本，导致 autoload 冲突
PHP cURL 扩展版本与 Guzzle 运行时行为不匹配
Guzzle v7+ 默认启用 CURLOPT_HEADERFUNCTION 等新选项，但某些 PHP 环境（尤其是旧版 cURL 库或 Alpine Linux 上的 musl libc）不支持，会直接触发 warning 或 silent fail，表现为 HTTP 请求无响应、重定向丢失、header 乱码等。
- 检查 PHP 的 cURL 版本：运行
php -r "echo curl_version()['version'] . \"\n\";"，低于 7.64.1 的建议升级系统 cURL - 临时绕过：在 Guzzle Client 构造时禁用新特性：
new \GuzzleHttp\Client(['curl' => [CURLOPT_HEADERFUNCTION => null]]) - 更稳妥的做法是统一环境：CI 和生产用相同基础镜像（如
php:8.2-apache而非php:8.2-cli），避免因构建环境差异引入 cURL 行为偏移
真正卡住的往往不是 Guzzle 本身，而是它上下游某个没打 tag 的私有包，或者 require-dev 里一个三年没更新的 mock 工具。排查时盯住 composer why-not 输出的最后一行，那才是真实封杀者。
