Composer报“requirements could not be resolved”本质是版本约束无交集，需用composer why-not定位阻断链、composer depends --tree查间接依赖，精确指定版本或兼容范围，并用--with-dependencies更新，同时校验PHP平台配置。
Composer 报“Your requirements could not be resolved”不是网络或权限问题，而是它已经穷举过所有版本组合，发现没有一个能满足全部约束——你得帮它找到那个交集点，而不是让它重试。
composer why-not 是定位封杀链的唯一可靠入口
报错里那句 Conclusion: don't install monolog/monolog 2.9.0 只是结果，真正卡住你的包藏在前面几十行。直接运行 composer why-not monolog/monolog:2.9.0，它会输出一条或多条阻断链，比如：
package-x v3.1.0 requires monolog/monolog ^1.25-
laravel/framework v10.32.0 replaces monolog/monolog (via symfony/error-handler)（注意 replace 也是硬规则）
别跳过 --tree 参数：composer depends --tree monolog/monolog 能看到谁在间接拉这个包——尤其是 require-dev 里的测试工具，常悄悄锁死主依赖。
改 composer.json 不是调数字，是找语义化版本交集
冲突本质是多个 ^1.25 和 ^2.10 没重叠。盲目写 "monolog/monolog": "^2.0" 可能没用，因为另一个包可能只认 >=2.8.0 。
- 去
Packagist查monolog/monolog的发布历史，找一个被上下游共同接受的版本，比如2.9.3（它同时满足^2.0和>=2.8.0） - 把约束改成精确版本：
"monolog/monolog": "2.9.3"，然后只跑composer update monolog/monolog - 如果必须横跨大版本，写
"monolog/monolog": "^1.25 || ^2.10"前，先确认你的代码真没调用Monolog\Logger::create()这类 v2 才有的方法——否则运行时才崩
定点更新要带 --with-dependencies，否则大概率失败
composer update monolog/monolog 单独执行经常报错，因为 Composer 默认不升级它的直系依赖（比如 psr/log），而新 monolog 可能要求 psr/log ^2.0，旧版却是 ^1.0。
- 必须加
--with-dependencies：composer update monolog/monolog --with-dependencies - 不要写
composer update "monolog/monolog:^3.0"—— 引号+波浪号会让解析器重新搜索，反而扩大搜索空间 - 更新后立刻
git diff composer.lock，确认只有monolog/monolog和它直接依赖的几行变了，没牵连phpunit或symfony/console
删 vendor 和 composer.lock 是最后手段，且要同步操作
它不是“重来”，而是放弃当前所有妥协记录，让 Composer 从头暴力求解。这在有 conflict、replace 或 30+ 包的项目里，可能卡住 10 分钟以上。
- 先跑
composer update --dry-run -v，看日志里是否反复出现Trying+ 回退 —— 如果是，说明 SAT 求解器已陷入指数级尝试 - 删之前，备份
composer.lock（比如重命名为composer.lock.bak），万一新解更糟还能回退 - 删完必须一起跑
composer install，不能只跑composer update—— 否则composer.lock仍为空，下次 CI 会失败
最易被忽略的一点：很多冲突其实来自 config.platform.php 和本地实际 PHP 版本不一致，比如锁文件里记着 php: 8.1，但你在 8.2 下跑 composer install，某些包的 conflict 字段会静默触发。查清环境再动手，比硬刷命令有用得多。
