Composer依赖冲突需先用composer why-not定位阻塞链，再通过composer update --lock适配PHP版本或composer update vendor/package --with-dependencies定点升级，避免删lock文件引发隐性问题。
composer install 报错 “Conclusion: don’t install xxx v2.1.0” 怎么办
这是 Composer 解析依赖图失败的典型表现，不是包本身有问题，而是当前 composer.json 中已声明的其他依赖（或其子依赖）锁死了某个包的版本范围，和你要装的新包冲突。
常见诱因：手动改过 require 但没跑 composer update；团队共用 composer.lock 但本地 PHP 版本或扩展不同；升级 Laravel、Symfony 等大框架后未同步更新生态包。
- 先运行
composer why-not vendor/package:version（比如composer why-not guzzlehttp/guzzle:^7.5），它会列出阻止安装的具体依赖链 - 不要直接删
composer.lock—— 这会重算整个依赖树，可能引入更多隐性冲突 - 如果只是想验证某个包能否装上，临时加
--dry-run：composer require vendor/package:version --dry-run
composer update 强制升级某几个包，但不碰其余依赖
composer update 默认会重算全部依赖，容易把线上稳定的子依赖也带偏。真要“定点更新”，必须显式列出包名，且不能带 ^ 或 ~ 这类模糊约束。
例如你只想升 monolog/monolog 到 3.0.0，同时保持 phpunit/phpunit 和所有其他包不变：
composer update monolog/monolog --with-dependencies
注意：--with-dependencies 是关键 —— 它允许 Composer 升级该包所需的最小依赖集，但不会去动 phpunit 这类无关项。如果不加，Composer 可能拒绝执行（报“无法满足要求”）。
- 避免写
composer update "monolog/monolog:^3"—— 引号 + 波浪号会让 Composer 尝试找兼容的最新版，而非精确指定版本 - 如果提示 “Your requirements could not be resolved”，说明该包的 v3 要求 PHP >=8.1，而你本地是 PHP 7.4 —— 此时不是命令问题，是环境不匹配
- 升级后立刻检查
git diff composer.lock，确认只有预期的包和其直系依赖被改动
composer require 时提示 “Package foo/bar is abandoned” 还能用吗
这不是错误，是 Composer 的提示性警告，意思是该包已由原作者标记为废弃（abandoned），通常会在 Packagist 页面显示替代包（如 foo/bar → newvendor/baz）。
能不能用？取决于两点：是否还有人维护镜像、你的代码是否调用了已弃用的 API。
- 查 Packagist 页面，看是否有
replaced by字段 —— 有就按提示换掉，别硬扛 - 如果没有替代包，且该包只做简单工具类（比如一个日期格式化函数），继续用风险较低；但如果是 HTTP 客户端、加密库这类底层组件，建议尽快迁移
- 用
composer show foo/bar看最后更新时间，如果两年没动静，又依赖ext-openssl这类敏感扩展，就得警惕
PHP 版本升级后 composer install 失败，锁文件里一堆 “requires php ^7.4”
composer.lock 里记录的是安装时的 PHP 约束，不是实时校验。PHP 从 7.4 升到 8.2 后，旧 lock 文件里的包可能仍声明只支持 7.4，导致 Composer 拒绝复现环境。
最稳做法不是删 lock 文件，而是让 Composer “重新理解”当前环境：
composer update --lock
这个命令不改依赖版本，只刷新 composer.lock 中的 PHP 平台信息和哈希值，适配新环境。
- 如果项目用了
config.platform.php（比如强制设为"7.4"），必须先删掉或改成当前 PHP 版本，否则--lock无效 - 某些包（如
doctrine/orm）在 PHP 8.2 下需要 v2.13+，而 lock 文件里锁的是 v2.10 —— 这时--lock不起作用，得走composer update doctrine/orm - CI 流水线里务必用
composer install --no-interaction --prefer-dist，别让平台配置差异引发非预期更新
依赖冲突从来不是版本数字的问题，而是约束叠加后的逻辑不可满足。每次报错都值得看一眼 composer why-not 的输出，比瞎删 lock 文件或硬加 --ignore-platform-reqs 管用得多。真正麻烦的往往不是冲突本身，是 lock 文件里混着不同 PHP 版本、不同 Composer 主版本下生成的平台约束，表面看着一样，实际解析规则已经变了。
