Composer 报错“Your requirements could not be resolved”本质是依赖约束无解，需从composer why-not输出的最后一行（根项目）倒推约束链，结合PHP版本、conflict字段、replace规则及require-dev干扰等综合排查。
Composer 报 “Your requirements could not be resolved” 不是网络或权限问题，而是当前所有已声明约束（包括 require、require-dev、lock 文件快照、PHP 平台配置）之间找不到一个共同满足的版本组合——它已经穷举过，没解。
composer why-not 显示一堆路径，怎么读才对
输出里每一行末尾的 (required by xxx) 是向上追溯的起点，必须从最后一行开始倒着看：最后一行是你自己的 composer.json，往上才是层层传递下来的约束链。比如：
monolog/monolog 2.10.0 requires php >=8.0 laravel/framework v10.35.0 requires monolog/monolog ^2.9 myapp/core v3.2 requires laravel/framework ^10.0 your-project requires myapp/core ^3.2
这说明你根项目要 myapp/core ^3.2，但它拉来了 L10，L10 要 monolog ^2.9，而 monolog 2.10.0 又强制要求 PHP 8.0+ —— 如果你本地是 PHP 7.4，冲突就在这儿卡死。
- 别指望
why-not直接告诉你“该删哪个包”，它只反映当前锁文件/已装状态下的约束快照 - 如果某行末尾是
conflict with vendor/pkg (>=2.0)，说明那个包自己写了conflict字段，不是 Composer 主动拦你 - 运行前先确认 PHP 版本：
php -v，再查composer show vendor/pkg看它实际装的是什么版本、require 列表长什么样
composer update 卡住或报 “don’t install X” 怎么办
这不是命令失败，是 Composer 明确拒绝：它算过所有可能组合，发现无解。盲目删 vendor/ 或 composer.lock 只会让下次 install 更难复现问题。
- 先跑
composer update --dry-run预演，看它打算动哪些包；加-v能看到具体哪条约束堵住了 - 想升某个包但被子依赖锁死？用
composer update vendor/package --with-dependencies，否则默认不更新它的依赖，大概率失败 - 不要写
composer update "vendor/package:^3"—— 引号 +^会让 Composer 去找兼容的最新版，而不是你心里想的那个“3.x 的某个确定版本” - 升级后立刻
git diff composer.lock，确保只有目标包及其直系依赖被改，没波及其他稳定模块
require-dev 悄悄拖垮生产环境依赖
require-dev 默认全程参与依赖解析，哪怕你部署时加了 --no-dev。比如 phpunit/phpunit 和主框架都依赖 sebastian/exporter，但 PHPUnit 锁死了 ^4.0，而框架要 ^5.0，Composer 就会直接放弃。
- CI/CD 中务必用
composer install --no-dev --optimize-autoloader，避免测试工具干扰主流程 - 若某个 dev 包反复引发冲突，考虑用
config.platform虚拟锚定它，例如：{"config": {"platform": {"phpunit/phpunit": "9.6.13"}}—— 它不真装，只提供版本参考 - 检查
composer show -t输出，重点看同名包是否在不同路径下被引用多个版本（如symfony/console出现在 Laravel 和 PhpUnit 两条线里），这是隐性冲突前兆
最常被忽略的一点：冲突未必来自你写的代码，而可能来自某个你没注意的 replace 或 conflict 字段——它们全局生效，哪怕你根本没 require 那个包，只要其他依赖间接拉进来了，就会触发。查 composer show vendor/package 的输出，翻到底部看 replaces 和 conflicts 字段，比猜更可靠。
