Composer旧项目升级版本冲突_Composer迁移至新版依赖修复法【方案】-composer-PHP中文网

先运行composer why-not laravel/framework:^10.0定位阻塞包，再显式执行composer update laravel/framework --with-dependencies，避免全量更新引发依赖错位，升级后核对composer.lock变更范围。

composer旧项目升级版本冲突_composer迁移至新版依赖修复法【方案】

旧项目升级不是“换几个版本号”就能过的事，Composer 会直接卡在 Resolving dependencies 或报 Your requirements could not be resolved —— 它不是算得慢，是根本找不到满足所有约束的解。

报错里只写 Conclusion: don't install laravel/framework:^10.0，但没说谁拦的。这时候敲 composer why-not laravel/framework:^10.0 才是正解。它的输出是“拒绝理由链”，必须从最后一行倒着读：

最后一行通常是你的根项目 myapp/myproject dev-main，它声明了某个依赖（比如 guzzlehttp/guzzle）的旧范围
往上一行可能是某个私有 SDK 或 require-dev 包（如 phpunit/phpunit）锁死了该依赖的版本
如果某行末尾带 (conflict with foo/bar >=2.0)，说明 foo/bar 自己写了 conflict 字段，Composer 是照章执行

composer update 默认重算全部依赖，容易把线上稳定的 symfony/polyfill-*、psr/log 全带偏。真要升框架或核心包，必须显式指定：

写法必须是 composer update laravel/framework --with-dependencies，不能带引号、不能加 ^ 或 ~
--with-dependencies 是关键：它只允许升 laravel/framework 所需的最小依赖集，比如 guzzlehttp/guzzle 和 symfony/http-foundation，但不会动 phpunit/phpunit
升级后立刻 git diff composer.lock，确认只有预期包及其直系依赖被改；多出一个 monolog/monolog 都可能埋运行时隐患

报 requires php ^8.1 but your php version is 7.4.33，这不是 Composer 故意卡你，而是它用当前 shell 的 php -v 结果去校验约束。常见误操作：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

以为切系统 PHP 就行，结果 CI 脚本里 php -v 还是 7.4
加 --ignore-platform-reqs 强装，结果 vendor/ 里塞进 PHP 8.1 语法（比如 match 表达式），一跑就 ParseError
改了 composer.json 里的 "php": "^8.1" 却没跑 composer update --lock，导致 composer.lock 还记着旧包

正确做法是明确指定 PHP 二进制路径执行：/usr/bin/php8.1 composer install（Linux/macOS）或 "C:\php\php81\php.exe" composer install（Windows）。

composer.lock 不是障碍，是当前已验证可行的依赖快照。删它等于扔掉唯一线索，重来一遍只会更难定位。遇到冲突时：

先跑 composer install --dry-run，预演哪条路径断了，比盲等 Resolving dependencies 有用得多
团队协作中拉新代码后报 Root requires X but Y is installed，大概率是别人提交了新 composer.json 却漏提 composer.lock，此时应 git checkout -- composer.lock 恢复再装
^1.2.3 和 ~1.2.3 看似只是写法差异，实际决定版本范围是否有交集：^1.2.3 允许所有 1.x，~1.2.3 只允许 1.2.x —— 这个细节常让依赖图无解