Composer install 报“could not be resolved”时，应先查看带 requires 的冲突主句、嵌套依赖链及末尾的 Conclusion 行，真正原因藏在数百行输出上方；用 composer why-not 可查某版本不可用原因，但不显示引入者，需配合 composer depends -r 使用。
composer install 报“could not be resolved”时，先看哪几行输出
这不是包没下载完，而是 Composer 在尝试满足某个 require 约束时卡住了。别急着删 vendor/ 或 composer.lock，直接加 -v 重跑：
composer install -v
重点盯住这几类输出：
- 形如
Root composer.json requires monolog/monolog ^2.4, but 2.4.0 conflicts with package-x的冲突主句 - 所有带
requires的嵌套链条，比如laravel/framework 10.42.0 requires php ^8.1→your-project requires php ^7.4 - 末尾的
Conclusion: don't install X行——它不是结论，是求解器放弃前的最后一搏，真正原因藏在上面几百行里
composer why-not vendor/package:version 能查什么、不能查什么
composer why-not 是定位“某个具体版本为何不可用”的最快方式，但它只回答“为什么这个版本装不上”，不回答“哪个包在锁死它”。
典型用法：
composer why-not guzzlehttp/guzzle:7.9.0
它会输出类似：
myapp/myproject dev-main requires guzzlehttp/guzzle (^7.2) monolog/monolog 3.5.0 requires guzzlehttp/guzzle (^7.5 || ^8.0) symfony/http-client 6.4.0 requires guzzlehttp/guzzle (^7.4)
注意：它不会告诉你 monolog/monolog 是被谁引入的——要查这个，得补一句：
composer depends -r monolog/monolog
常见盲区：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果输出为空，说明该包根本没出现在当前依赖图里（可能被
conflict排除，或仅存在于require-dev） - 它不检查
platform配置是否与真实 PHP 版本冲突，这类问题得靠composer check-platform-reqs单独验证
^、~、= 这些版本约束到底怎么算
Composer 的版本解析不是字符串匹配，而是基于语义化版本（SemVer）的数学推导。写错一个符号，可能让 composer update 升到破坏性大版本。
关键规则：
-
^1.2.3≡ 允许升级到1.x.x中所有兼容版本，即 ≥1.2.3 且 ^0.1.2 只允许 -
~1.2.3≡ 允许补丁级升级，即 ≥1.2.3 且 ~1.2 等价于~1.2.0 -
=1.2.3是硬锁定，但 Composer 仍可能因依赖传递强制升级——除非你同时写"prefer-stable": true并禁用--with-dependencies
容易踩的坑：
- 写
"monolog/monolog": "^1"—— 它等价于"^1.0.0"，但如果你项目实际需要^2.0功能，这个约束会让 Composer 死守 1.x，报错却不提示你该升主版本 - 用
"dev-main"或"*@dev"：它们绕过 SemVer 检查，也不进composer.lock的哈希校验，上线后极易因远程分支变更导致行为漂移
PHP 版本升级后，为什么 composer update 不重算依赖
Composer 不把 PHP 版本当“可变依赖”，它只在首次解析或 lock 文件缺失时，才基于当前环境重新计算整个依赖图。一旦 composer.lock 存在，它就复用里面为旧 PHP 版本解出的包版本。
后果很直接：你在 PHP 8.2 下运行 composer update，它仍可能装上一个只声明支持 php: ^7.4 的包——只要 lock 里记着它。
必须做的三件事：
- 执行
composer clear-cache：清掉平台感知缓存，否则它可能沿用 PHP 8.1 的扩展可用性判断 - 用
composer update --with-all-dependencies：普通update只动顶层require，而这个参数会放开所有间接依赖（如symfony/console被laravel/framework引入）的版本锁 - 别碰
--ignore-platform-reqs：它跳过php和ext-*校验，装上不兼容包，等运行时报Call to undefined function才发现，调试成本翻倍
最隐蔽的问题往往出在 config.platform.php：它会覆盖真实 PHP 版本，让 check-platform-reqs 检查假环境。本地开发建议删掉这一段，只在 CI 中保留。
