先运行 composer install -v 查看具体冲突包及约束，再用 composer why-not 定位不可用原因；检查 require 与 require-dev 冲突可试 --dry-run 或 --no-dev；升级前核对 changelog 并小范围更新；确认 config.platform.php 与实际 php 版本一致。
composer install 报错 “Your requirements could not be resolved” 怎么快速定位冲突点
这通常不是依赖没装全，而是 composer.json 里写的版本约束和已有的 lock 文件、或远程包元数据对不上。别急着删 vendor 或 composer.lock，先让 Composer 自己说清楚哪卡住了。
- 运行
composer install -v（加-v不是看日志长度，是让它吐出具体哪个包在尝试满足什么约束时失败） - 重点盯输出里形如
Root composer.json requires package-a ^1.2, but package-a 1.2.0 conflicts with another require的那几行 - 如果输出太长，用
composer why-not vendor/package:version直接查某个版本为何不可用，比如composer why-not monolog/monolog:2.10.0
require 和 require-dev 的依赖互相打架怎么办
开发依赖（require-dev）里的包，比如 phpunit/phpunit 或 friendsofphp/php-cs-fixer，经常带一堆高版本的工具链依赖，一不小心就把生产依赖（require）拖垮——尤其是它们都依赖同一个底层库（比如 symfony/console）但要的主版本不同。
- 执行
composer update --dry-run，它不会改任何文件，但会模拟整个解析过程，暴露出真实冲突路径 - 临时注释掉
require-dev块，跑一次composer update --no-dev，确认生产依赖本身是否干净；如果干净，问题就出在 dev 包上 - 不要盲目升级
require-dev里的所有包，优先锁定和你当前 PHP 版本、框架版本真正兼容的组合，比如 Laravel 9 + PHP 8.1 就别硬上 php-cs-fixer v3.20+
composer outdated 显示一堆“可升级”，但 upgrade 后直接崩
composer outdated 只比对本地 composer.lock 和 Packagist 最新版本，不验证兼容性。它说“有新版”，不代表“能升”。尤其当项目用了大量 ^ 或 ~ 约束时，一个小版本跳变可能触发语义化版本外的破坏性变更。
- 升级前先看目标包的 CHANGELOG 或 GitHub Releases，重点关注
BC BREAK、Deprecation标签 - 用
composer update vendor/package --with-dependencies替代全量 update，缩小影响范围 - 如果项目有测试，升级后必须跑
vendor/bin/phpunit；没有测试？至少手动过一遍核心流程，比如登录、下单、导出——很多问题只在运行时暴露，不在安装时
PHP 版本不匹配导致依赖无法安装
Composer 会读取 config.platform.php 或当前运行环境的 PHP 版本，去过滤不兼容的包版本。如果你本地是 PHP 8.2，但 composer.json 里写了 "config": {"platform": {"php": "7.4.0"}}，那所有只支持 8.0+ 的包都会被无视，哪怕它们其实是安全的。
- 检查
composer.json里有没有config.platform.php，有就删掉或改成和你实际环境一致的值 - 运行
php -v和composer show --platform对比，确认 Composer 看到的 PHP 版本是不是你预期的 - 某些共享主机或 CI 环境里，CLI 和 Web 使用的 PHP 版本不同，此时
composer install成功但运行时报错，得统一排查两处环境
最麻烦的不是报错信息本身，而是 Composer 在 resolve 阶段做的隐式约束推导——它会把间接依赖、平台配置、稳定性标志（minimum-stability）全搅在一起算。所以别信“重装一遍就好”，先看 -v 输出里那一长串“trying”记录，那里藏着真实瓶颈。
