“Your requirements could not be resolved”不是网络或权限问题，而是本地环境不满足约束导致无解；应优先运行composer why-not定位冲突源头，结合composer show --tree查看真实依赖结构，而非盲目删vendor或composer.lock。
“Your requirements could not be resolved” 不是网络问题，是本地约束无解——删 vendor 或 composer.lock 不能修复它，只会重跑一遍失败逻辑。
看到 “don’t install xxx:version” 就该运行 composer why-not
这是定位冲突源头最直接的命令。报错里说不装 monolog/monolog:2.9.0，就立刻执行：composer why-not monolog/monolog:2.9.0
- 输出从下往上读：最后一行是你
composer.json的根声明，往上每行末尾的(required by)就是提出互斥约束的包 - 如果输出为空，检查
require-dev——phpunit/phpunit、mockery/mockery常拖着老版sebastian/exporter，间接锁死symfony/console - 别信报错第一行，盯住末尾几行带
Root package requires和requires php的部分，常暴露 PHP 版本或扩展卡点
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里确认它实际提供什么
升级或降级单个包必须加 --with-dependencies
不加这个参数，Composer 默认拒绝更新目标包的子依赖，哪怕新版本根本跑不起来：
- 正确写法：
composer update guzzlehttp/guzzle --with-dependencies - 错误写法：
composer update "guzzlehttp/guzzle:^7"—— 引号 +^会让 Composer 自己找“最新兼容版”，不是你要的7.4.5 - 跨主版本降级（如从
^8.0切回7.4.5），必须先在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，再执行 update - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他
镜像配对了 ≠ 真生效，-vvv 才是唯一验证方式
composer config -g repo.packagist 输出 JSON ≠ 镜像已走通。真正要看的是请求地址：
- 运行
composer install -vvv，第一行如果是Downloading https://packagist.org/packages.json，说明根本没走你配的阿里云镜像 - 项目根目录
composer.json里只要存在"repositories": []（哪怕空数组），全局配置就彻底失效 - CI/CD 或宝塔环境常见权限错位：用
sudo配的全局镜像是 root 的，但实际跑命令的是www用户，得用sudo -u www composer config -g repo.packagist - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
真正难的不是命令怎么敲，而是理解 Composer 不是在“安装包”，而是在求解一个满足所有约束的布尔方程；composer.lock 是解，composer.json 是题干，任何跳过题干直接改答案的操作，都会让下次求解更难。
