报错“your requirements could not be resolved”时应先看末尾两行：root composer.json requires...和found conflicting requirements for...，它们明确指出谁提需求、谁卡脖子；再用composer why-not定位阻塞链，从最后一行（根需求）向上逆推，重点识别版本无交集或conflict字段所在层级。
报错“Your requirements could not be resolved”时先看哪几行
别扫完整段报错，直接跳到末尾两段：一是 Your requirements could not be resolved 后面紧跟的 Root composer.json requires ...，二是 Found conflicting requirements for ...。这两行告诉你谁在提需求、谁在卡脖子。比如看到 Root requires guzzlehttp/guzzle:^7.2，但下面写 spatie/laravel-backup v7.2.0 requires guzzlehttp/guzzle:^6.5，冲突点就不是 Guzzle 本身，而是它被两个包锁在互斥区间。
用 composer why-not 定位真实拦路虎
报错说不能装 laravel/sanctum:^3.0？别改自己的 composer.json，先跑：composer why-not laravel/sanctum:^3.0
输出里最后一行是你的根需求，往上每行末尾的 (required by ...) 是传递链。重点找带 conflict with 或版本范围无交集（如 ^5.4 vs ^6.2）的那一层。常见陷阱：
- 某行显示
phpunit/phpunit 10.5.0 → requires symfony/console ^6.4，而另一行是myapp/core v2.1 → requires symfony/console ^5.4—— 真正要调的是symfony/console，不是phpunit或laravel/sanctum - 如果输出提示
No installed package depends on ...，说明冲突来自config.platform或根require的显式声明，回头检查composer.json里的"php"和"ext-xxx"配置
查依赖树得用 composer show --tree，不是靠猜
composer show --tree 显示的是当前 vendor/ 和 composer.lock 的真实快照，不是你想象中的依赖关系。很多冲突藏在第二、三层，比如某个测试工具悄悄拉进不兼容的 doctrine/dbal。
实操建议：
- 用
composer show --tree | grep "symfony/console"快速定位它被谁引入、是否已锁定（如(locked to 5.4.32)） - 查某个包的完整路径：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle" - 注意
require-dev默认参与解析——phpunit/phpunit常带高 PHP 版本要求，却最容易被忽略
调整版本前必须验证，别直接 composer update
盲目运行 composer update 可能放大冲突或破坏功能。先做最小验证：
- 跑
composer update --dry-run --with-dependencies vendor/package：只算不改，看是否仍冲突、影响哪些包 - 去 Packagist 查目标包的
require字段，确认它真兼容你当前的关键依赖（如laravel/framework版本） - 临时建分支，执行
composer require vendor/package:desired-version --no-update && composer update --with-all-dependencies，把变更隔离出来测 - 慎用
--ignore-platform-reqs：它绕过 PHP 版本或扩展检查，但不会消除真实约束——运行时大概率报Call to undefined method
真正难的不是找到命令，是读懂 why-not 输出里那条「拒绝理由链」的倒序逻辑，以及分清哪个包是源头、哪个只是中间传话的。每次调整后记得跑测试，有些问题不会在安装时报，而是在第一次调用某个方法时才暴露。
