Composer 报错“Your requirements could not be resolved”表明依赖无解，需用 composer why-not 查阻塞链，优先检查 require-dev 和 PHP 版本约束，并用 composer show --tree 验证真实依赖结构。
看到 “Your requirements could not be resolved” 不是网络问题，是 Composer 已穷尽所有组合后确认无解——得让它把“为什么不行”摊开给你看。
报错里出现 don’t install xxx 就该立刻 run composer why-not
这行不是提示“别装”，而是明确告诉你：某条依赖链正在封杀这个版本。直接执行 composer why-not vendor/package:version（比如 composer why-not guzzlehttp/guzzle:^7.5），输出是倒序阻塞链：
- 最上面一行通常是
Root package requires，说明你composer.json里写了过窄的约束，比如"php": "7.4"或"monolog/monolog": "2.9.0" - 中间带
(required by package-a v1.2)的行，说明是间接依赖在提要求；别急着删它，先查 Packagist 页面，看它是否已有支持新版的 release - 如果输出为空，优先检查
require-dev—— 很多冲突来自phpunit/phpunit或mockery/mockery拖着老版sebastian/exporter
用 composer show --tree 看真实依赖结构，不是愿望清单
composer.json 是你写的愿望，composer.lock 和 vendor/ 才是现实。运行 composer show --tree 能暴露你根本没意识到的路径：
- 查某个包被谁引入：
composer show --tree | grep "symfony/console"，注意是否标着(locked to 5.4.42) - 查两个包之间的实际关系：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle" - 看到
(replaced)或(provided)？得去那个包自己的composer.json查replace字段，确认是否真能等价替代
升级或降级单个包必须加 --with-dependencies
默认 composer update vendor/package 会拒绝更新其子依赖，哪怕新版本根本跑不起来——这是最常踩的坑：
- 升版本：
composer update monolog/monolog --with-dependencies，只动它和直系依赖 - 降主版本（如从
guzzlehttp/guzzle:^8.0切回7.4.5）：必须先在composer.json里写死"guzzlehttp/guzzle": "7.4.5"，再跑composer update guzzlehttp/guzzle --with-dependencies - 错误写法：
composer update "monolog/monolog:^3"—— 引号 +^会让 Composer 自己选“最新兼容版”，不是你要的3.0.0 - 执行后立刻
git diff composer.lock：只接受目标包及其直系依赖变更；如果多了十几个包，说明约束没控住，得回退
“Could not find a matching version” 不是找不到包，是版本写错了
这不是镜像源或网络问题，是你写的版本约束在当前所有源中确实不存在对应 tag、分支或稳定性标签：
- 先验证事实：
composer show -a vendor/package-name（如composer show -a guzzlehttp/guzzle），它列出全部真实发布的 tag 和分支，每行末尾标着(stable)、(RC)、(dev) - 写了
^2.0却装不到2.3.0？可能2.3.0根本没发布，或者只存在于dev-main分支，而你没允许开发版 - 私有包或 Git 仓库必须显式声明：
repositories配置缺一不可，且type要设为vcs，url必须可直连 - 想临时装
dev-main，别改全局minimum-stability，用命令行指定：composer require vendor/package:dev-main --stability=dev
真正难的不是命令怎么敲，而是读得懂 composer why-not 输出里哪一行才是真正的源头——有时它藏在 require-dev 里，有时卡在 PHP 版本判断上，有时只是你漏看了 (provided) 声明。别跳过 --dry-run -v，也别绕过 git diff composer.lock，这两步省了，后面花的时间更多。
