composer why-not 是定位版本冲突源头的首要命令，输出拒绝链需倒序阅读，最后一行（如 spatie/laravel-backup v7.2.0）即真正拦路包；必须指定完整版本号（如 2.9.0），^2.0 无效；空输出说明该版本未被任何启用依赖声明，可能源于 require-dev 残留或镜像未同步。
用 composer why-not 定位谁在封杀目标版本
报错里出现 Your requirements could not be resolved 时，真正拦路的往往不是你写的 require，而是某个间接依赖偷偷锁死了版本。比如你想装 monolog/monolog:2.9.0，但 package-x v3.1.0 明确要求 monolog/monolog:1.25.0，它就直接把你卡死。
运行 composer why-not monolog/monolog:2.9.0，输出会逐层列出所有阻止该版本安装的包及其约束条件。重点看最后一行（例如 for spatie/laravel-backup v7.2.0），那个才是你真正要动的包。
- 必须写完整版本号，
2.9.0有效，^2.0无效 - 别用
composer depends—— 它只告诉你“谁用了它”，不告诉你“谁不让升” - 如果输出为空，说明这个版本根本没被任何已启用依赖提及，可能是
require-dev残留或镜像源未同步
用 composer update --dry-run -v 看 SAT 求解器怎么卡住的
Composer 解析依赖本质是跑 SAT 求解器，不是拼凑列表。当它卡在 Resolving dependencies through SAT 超过 2 分钟，说明约束太紧，正在暴力回溯试错。
加 --dry-run -v 不改任何文件，但完整走一遍求解流程。日志末尾会出现类似这样的冲突摘要：
Because package-a v2.1 requires symfony/console ^5.4, and package-b v3.0 requires symfony/console ^6.0.
这比报错文字更准——它直接告诉你哪两个包在打架。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 加
-vvv会输出完整决策树，但信息过载；-v足够定位主因 - 别跳过
--dry-run直接update，否则失败后还要清理 vendor 和 lock - 若反复看到同一包名（如
symfony/polyfill-php81）出现在Trying行，说明它是解析瓶颈点
检查 require-dev 是否悄悄引入高版本依赖
很多冲突实际来自测试工具链。比如主项目用 laravel/framework:^10.0，但 orchestra/testbench:^8.0 内部硬绑 laravel/framework:^11.0，composer install 就会直接崩。
运行 composer update --no-dev --dry-run -v，如果冲突消失，问题八成出在 require-dev。
-
phpunit/phpunit、mockery/mockery、laravel/pint是高频冲突源 - 临时注释掉整个
require-dev区块，再跑composer update --dry-run快速验证 - 不要在
require-dev里塞和主项目不兼容的大版本包，宁可拆到单独的 CI 配置中
确认 PHP 平台版本是否被忽略
报错里没提 PHP，不代表它不相关。比如 symfony/console:^6.4 要求 php: >=8.1，而你本地是 php 8.0.30，Composer 就会默默排除所有满足条件的版本，最终无解。
运行 php -v 确认真实版本，再检查 composer.json 的 config.platform.php 是否设对：
"config": {
"platform": {
"php": "8.1.0"
}
}
- 没配
platform.php时，Composer 用当前运行环境 PHP 版本解析，容易和部署环境不一致 - 配了但值低于实际版本（如写
"php": "8.0"而本地是 8.2），会导致错过更高版本包 - 某些包（如
doctrine/dbal）会同时声明php和扩展依赖（ext-pdo_sqlite），缺一不可
最常被跳过的其实是 require-dev 的参与度和 platform.php 的缺失——它们不报错，但让 SAT 求解器在看不见的地方反复失败。
