composer install 报“your requirements could not be resolved”是依赖树无解冲突，需用 composer why-not 或 prohibits 定位阻塞包，检查 platform 配置、php 版本对齐、稳定性设置及 lock 文件完整性。
composer install 报 your requirements could not be resolved 怎么办
这其实是依赖树冲突的典型提示，不是版本号写错了，而是 Composer 在尝试满足所有 require 和 require-dev 时发现无解路径。常见于项目升级后、换环境重装、或引入新包时。
先别急着删 composer.lock 或强制加 --ignore-platform-reqs——那只是掩盖问题。
- 运行
composer why-not vendor/package:version查具体哪个包在阻止安装（比如composer why-not laravel/framework:v11.0） - 用
composer prohibits vendor/package:version看谁显式/隐式锁死了冲突版本 - 检查
platform配置：如果composer.json里有"platform": {"php": "8.1"}，但实际是 PHP 8.2，也会触发这类报错
dev-main / dev-develop 被拒绝安装
Composer 默认不装开发分支，除非你明确允许并配置了稳定性标志。这不是 bug，是设计行为。
- 加
--stability=dev参数：比如composer require monolog/monolog:dev-main --stability=dev - 或在
composer.json顶层加"minimum-stability": "dev"（不推荐长期使用，会影响所有依赖） - 更稳妥的做法是临时改
"prefer-stable": true为false，装完再改回来 - 注意：某些包的
dev-main可能没定义autoload或缺少composer.json，会直接失败，得看 GitHub 上的分支结构
PHP 版本不匹配导致的 requires php ^8.0 报错
Composer 会校验当前 PHP 版本是否满足 require.php 和各包的 php 约束。报错时它说的不是“你该升级 PHP”，而是“你声明的平台版本和实际不符”。
- 确认当前 PHP 版本：
php -v；再查composer show php看它认为的平台版本 - 如果用的是 Docker 或多版本管理器（如
asdf），可能 CLI 和 Composer 调用的不是同一个 PHP - 临时绕过：加
--ignore-platform-req=php，但仅限调试；生产环境必须对齐 - 长期方案：在
composer.json的config.platform.php里写死目标版本，比如"platform": {"php": "8.1.10"}，避免本地环境干扰
更新单个包却触发全量重解析
执行 composer update vendor/package 本应只动那个包，但若它的子依赖在 composer.lock 中缺失或版本模糊（比如只写了 ^2.0 没锁死小版本），Composer 就会重新跑整个依赖图。
- 检查
composer.lock里该包及其依赖是否都有确定的dist.reference（即 commit hash 或 tag） - 避免用
composer update不带参数，尤其在线上 CI 环境——它会忽略composer.lock的约束 - 想最小化变更？先
composer show vendor/package看当前装的是什么版本，再指定精确版本更新：composer require vendor/package:2.3.4 - 注意：
require命令默认走update流程，不是install，所以依然会重算依赖
最麻烦的其实是嵌套的 conflict 声明和私有仓库的元数据延迟——这些不会直接报错，但会让 why-not 返回空，得手动进 vendor/composer/installed.json 对比已装版本和约束范围。
