答案是运行composer why-not vendor/package:version定位阻塞链——输出倒序显示依赖层级，最后一行是根require，往上每行“(required by)”即封杀源头；该错误源于SAT求解失败，非网络或缓存问题。
直接运行 composer why-not vendor/package:version，它能立刻告诉你谁在拦路——不是网络问题，也不是缓存没清，而是你写的约束和现有依赖树根本没交集。
报错 “Your requirements could not be resolved” 怎么定位卡点
这个错误发生在 Composer 本地 SAT 求解阶段，元数据早已拉完，失败纯属逻辑冲突。别删 vendor 或 composer.lock，先看报错末尾那句 don't install xxx，然后立刻执行：
-
composer why-not psr/log:3.0.0（必须带完整版本号，^3.0或3可能匹配不到） - 输出是倒序链：最后一行是你
composer.json的根声明，往上每行末尾的(required by)就是真正封杀者 - 如果输出为空，优先检查
require-dev——比如phpunit/phpunit常拖着老版sebastian/exporter，间接锁死symfony/console
升级或降级单个包时为什么总失败
因为默认 composer update vendor/package 只动那个包本身，子依赖纹丝不动。结果就是 Laravel 升到 11，symfony/console 还卡在 v5.4，一跑命令就报 Class "Symfony\Component\Console\Command\Command" not found。
- 必须加
--with-dependencies：例如composer update laravel/framework --with-dependencies - 想降主版本（如从 Guzzle 8 切回 7.4.5），得两步走：
"guzzlehttp/guzzle": "7.4.5"写死进composer.json，再执行composer update guzzlehttp/guzzle --with-dependencies - 别写
composer update "guzzlehttp/guzzle:^7"—— 引号 +^会让 Composer 自己找“最新兼容版”，不是你要的 7.4.5
怎么确认真实依赖结构而不是靠猜
composer.json 是你写的愿望清单，composer show --tree 才是当前 vendor/ 和 composer.lock 里的真实快照。它会暴露你根本没意识到的间接路径：
- 看到
(locked to 5.4.42)？说明该版本被composer.lock固定，不是你当前composer.json决定的 - 看到
(replaced)或(provided)？得去那个包自己的composer.json里确认它到底替代了什么、是否真能覆盖全部 API - 过滤查看：例如
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"
最常被忽略的是 require-dev 里的包，它们不参与生产环境，但会悄悄锁死整个依赖树；还有手动改 composer.lock —— 它不是配置文件，是哈希快照，改错一个字段，下次 install 就直接失败。
