直接用 composer create-project laravel/laravel:^5.8 通常失败，因 laravel 5.8 对 guzzlehttp/guzzle、symfony/* 等依赖版本敏感，易触发 composer sat 求解器卡死或“requirements could not be resolved”错误；根本原因是本地已有包（如 socialite v4.x）与 laravel 5.8 的 symfony/http-foundation v4.3 冲突，导致 guzzlehttp/guzzle 版本约束不可满足。
直接用 composer create-project laravel/laravel:^5.8 通常会失败——Laravel 5.8 虽然支持 PHP 7.1.3+，但它的依赖树对 guzzlehttp/guzzle、symfony/* 和 phpunit 等包的版本非常敏感，尤其在 macOS 上，全局 Composer 缓存或旧版锁文件常导致 SAT 求解器卡死或报错 “Your requirements could not be resolved”。
为什么 composer require laravel/framework:5.8.* 会触发 Guzzle 冲突
Laravel 5.8 自身不直接声明 guzzlehttp/guzzle，但它通过 guzzlehttp/psr7 和邮件驱动间接依赖；而你本地已有的包（比如 anhskohbo/no-captcha v3.3.0 或某个旧版 SDK）可能硬绑了 guzzlehttp/guzzle:^6.2，同时又和 Laravel 5.8 的 symfony/http-foundation v4.3 不兼容。Composer 无法同时满足 ^6.2 和 ^7.0，于是报错：
Problem 1 - guzzlehttp/guzzle[7.4.0] requires guzzlehttp/promises ^1.5 but your lock file fixes it at 1.4.1
这不是网络问题，是约束逻辑不可解。
- 别先删
vendor或跑composer update——这会让冲突更隐蔽 - 先运行
composer why-not guzzlehttp/guzzle:7.4.0，看哪条路径在阻断 - 常见阻断源：
laravel/socialitev4.x（要求 Guzzle 6）、league/flysystem-aws-s3-v3v1.x（锁死guzzlehttp/psr7:1.4）
安全安装 Laravel 5.8 的三步操作流
Mac 上最稳的方式不是“重装”，而是“精准协调”：
- 清空当前项目缓存但保留全局 Composer 配置：
composer clear-cache，再进缓存目录确认~/.composer/cache/files/为空 - 删掉现有
vendor/和composer.lock（如果已有） - 用带依赖联动的命令一次性拉齐：
composer create-project laravel/laravel:^5.8 myapp --no-dev -W
其中 -W（即 --with-all-dependencies）是关键：它强制 Composer 重新计算整个依赖图，把 guzzlehttp/promises、guzzlehttp/psr7、symfony/polyfill-php72 全部按 Laravel 5.8 的 composer.json 声明做语义化对齐，而不是沿用旧锁。
装完必须验证的两个点
很多人以为 create-project 成功就万事大吉，其实 Laravel 5.8 在 macOS 上最容易漏检的是：
-
php artisan tinker报Class 'GuzzleHttpClient' not found：说明guzzlehttp/guzzle没真正加载，检查vendor/composer/autoload_psr4.php里是否有"GuzzleHttp\" => array($vendorDir . '/guzzlehttp/guzzle/src') -
php artisan serve启动后访问 500 错误：大概率是symfony/var-dumper版本过高（v5+），Laravel 5.8 只兼容symfony/var-dumper:^4.3，可手动执行composer require symfony/var-dumper:^4.3 --no-update && composer update --lock
复杂点不在命令多，而在每个包的版本号背后都有隐式约束链；Mac 用户尤其要注意 Homebrew 安装的 PHP 和 CLI 实际调用的是否一致——which php 和 php -v 输出不一致时，composer 可能用错 PHP 扩展路径，导致 mbstring 或 openssl 显示已启用实则未加载。
