遇到 Your requirements could not be resolved，别删 composer.lock —— 它不是故障源，而是当前唯一已知“能跑”的状态快照。真正要做的，是让 Composer 把推理过程摊开给你看。
用 composer update --dry-run -v 看清冲突起点
这个命令不改任何文件，但会完整执行依赖求解，并在末尾几行直接写出矛盾点。关键信息集中在：
- 以
Conclusion:开头的句子（比如Conclusion: don't install monolog/monolog 2.10.0），这是它回溯出的第一个不可满足节点 -
Root requirements段落：明确指出你composer.json里哪一行触发了整条链，例如"laravel/framework": "^10.0" -
Found conflicting requirements段落：列出互斥约束，如package-a requires symfony/console ^5.4但package-b requires symfony/console ^6.0 - 反复出现的包名（如
monolog/monolog、guzzlehttp/guzzle）大概率是冲突枢纽，优先盯住它们
用 composer why-not 定位“谁在拦路”
它模拟安装失败路径，精准定位首个不兼容依赖。必须指定完整包名+版本号，例如：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer why-not laravel/framework:10.0→ 查为什么 Laravel 10 装不上 -
composer why-not php:^8.3→ 查哪个已装包只支持 PHP 8.2 或更低 - 如果报
[InvalidArgumentException] Package not found，说明该包还没在composer.json或composer.lock中声明过，命令无效 - 输出中若含
ext-intl或ext-gd，就去运行php -m验证扩展是否启用
用 composer prohibits 反查“谁被它拦了”
当某个包卡在旧版升不上去，用它查谁在强制锁版本：
-
composer prohibits monolog/monolog:^2.0→ 查哪些包写了"monolog/monolog": "^1.25"或"conflict": {"monolog/monolog": "^2.0"} - 结果会显示具体包名、版本、以及它的
composer.json中哪条约束起了作用 - 注意区分
requires（真正在拉依赖）和replaces/provides（无关干扰项） - 如果输出为空，说明没有包显式排斥该版本，问题可能出在
config.platform或 PHP 实际版本不匹配
小心 require-dev 和 config.platform 这两个隐形推手
开发依赖和平台配置不显眼，却常是冲突根源：
-
require-dev里的phpunit/phpunit、phpstan/phpstan等工具，往往带高版本symfony/console或强 PHP 版本要求，和生产依赖打架 - 试
composer update --no-dev，如果成功，说明问题就在require-dev；再逐个注释掉 dev 包定位元凶 -
config.platform.php是伪造的 PHP 版本，若设为"8.1"但实际环境是8.2，Composer 会按假版本选包，导致某些真实可用的版本被过滤掉 - 检查
composer.json顶层的"php": "..."是否和本地php -v一致，不一致时 Composer 会直接拒绝满足该约束的包
真正难的不是命令怎么敲，而是看到 why-not 输出里同时出现 some/sdk v3.1.0 requires php (^7.4) 和 Root composer.json requires php (^8.2) 时，得立刻意识到：这个 SDK 已不维护，要么降 PHP，要么换替代方案——工具只能暴露问题，解法得人来判。
