生产环境依赖冲突需用composer why-not直击阻塞点，而非删vendor或清缓存；CI失败而本地成功主因是PHP版本或扩展不一致，如CI缺pcntl扩展或platform配置与实际不符，且--no-dev缺失会掩盖dev依赖引发的线上冲突。
生产环境依赖冲突不是“重装就能好”的临时故障，而是约束条件在真实运行环境中暴露的不可解性——必须用 composer why-not 直击阻塞点，而不是靠删 vendor 或清缓存蒙混过关。
为什么 composer install 在 CI/CD 里失败，但本地能过？
根本原因常是 PHP 版本或扩展不一致：CI 环境用的是 php:8.2-cli 镜像，而你本地开发机跑的是 php -v 显示 8.1，但 php -m 漏了 mbstring；或者 composer.json 里写了 "php": "^8.1 || ^8.2"，可某个依赖（比如 spatie/laravel-ray）悄悄要求 ext-pcntl，而 CI 容器默认不启用它。
- 先在 CI 脚本开头加两行：
php -v和php -m | grep -E "mbstring|openssl|curl|json|pcntl" - 检查
composer.json的config.platform.php是否被设成固定值（如"8.1.0"），这会让 Composer 忽略真实环境，导致锁文件生成时“假装”有某个扩展 - 别信
composer diagnose——它只查配置语法，不验扩展可用性；真正要跑的是php -r "extension_loaded('mbstring') || die('missing');"
composer why-not 输出为空，但安装还是失败
空输出 ≠ 没冲突，大概率是目标版本没被元数据收录，或镜像未同步。比如你想装 guzzlehttp/guzzle:^8.5，但阿里云镜像还没拉到这个 tag，why-not 就找不到任何约束来源。
- 先确认镜像生效：
composer config -g repos.packagist输出必须是完整 JSON，且url字段指向https://mirrors.aliyun.com/composer/ - 再查项目级覆盖：
composer config repo.packagist（不带-g），如果返回空或报错，说明项目composer.json里有"repositories"字段屏蔽了全局镜像 - 手动验证包是否存在：
curl -I https://mirrors.aliyun.com/composer/p2/guzzlehttp/guzzle.json | head -1，返回200才算真同步到了
锁文件冲突标记还在，但 composer update --lock 不起作用
composer.lock 出现 合并冲突标记后，--lock 只会重建哈希，不会自动清理这些标记——它把冲突当普通文本读，结果解析失败。
- 别手动删整个
composer.lock，先用git checkout -- composer.lock回退到干净版本 - 然后运行
composer update --lock --no-scripts，跳过post-update-cmd避免脚本干扰解析 - 如果仍报错，说明
composer.json本身有语法错误或非法字段（比如多了一个逗号），用php -l composer.json验证
升级 Laravel 主版本后，php artisan 报类不存在
这不是 autoload 问题，而是 composer update 没带 --with-dependencies，导致主包升了，但它的子依赖（比如 symfony/console）还卡在旧版，autoload 规则对不上。
- 正确操作是：
composer update laravel/framework --with-dependencies - 验证是否真更新到位：
composer show symfony/console，不能只看laravel/framework的版本 - 如果
show显示的仍是旧版，说明有其他包（比如某个自定义命令行工具）硬性require了旧版，这时得用composer prohibits symfony/console:^6.0找出谁在拦路
最易被忽略的一点：生产环境的 composer install 必须加 --no-dev，否则 require-dev 里的包（如 phpunit/phpunit）可能拖进一个与主框架冲突的 sebastian/exporter 版本，而这个冲突在本地 install 时不触发——因为本地没加 --no-dev，Composer 会把 dev 包也纳入求解范围，掩盖了真实矛盾。
