这不是 composer 坏了，而是你当前 composer.json 里声明的依赖组合，在 packagist 上找不到一个共同满足所有约束的版本解——必须人工干预，不能靠重试或清缓存解决；应优先用 composer why-not（带完整版本号、倒序读输出）、composer show --tree 分析依赖树，再定点 update 或降级，慎用 --no-update 和 replace。
直接结论：这不是 Composer 坏了，而是你当前 composer.json 里声明的依赖组合，在 Packagist 上找不到一个共同满足所有约束的版本解——必须人工干预，不能靠重试或清缓存解决。
报错 “Your requirements could not be resolved” 怎么定位真凶
别急着删 vendor 或 composer.lock。这个错误是 Composer 解析器明确告诉你“无解”，不是临时故障。
- 先运行
composer why-not vendor/package:version（比如composer why-not topthink/framework:^8.0），注意必须带完整版本号，^8或8.0会报Package not found - 输出结果从下往上读：最后一行是你自己的根依赖（如
myapp/project dev-main requires topthink/framework ^5.1），往上每行末尾的(required by xxx)就是卡住你的实际包 - 如果看到
spatie/laravel-backup v7.2.0 requires symfony/console ^5.4，而另一个包要求^6.2，那真正断点是symfony/console，不是框架本身
用 composer show --tree 看清依赖快照
执行 composer show --tree | less -S，重点盯三类信息：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 同名包是否被多个路径引入不同版本（例如
symfony/console同时出现在topthink/think-orm和phpunit/phpunit下） - 某行末尾标了
(locked to 5.4.42)—— 这个版本已被composer.lock硬锁死，不改它就不可能升级 - 出现
(replaced)或(provided)的包，立刻去 Packagist 查它的composer.json，确认replace字段是否真能等价替代
精准更新或降级，别碰全量依赖
全量 composer update 容易把稳定包也带偏，风险高。优先用定点操作：
- 若发现
symfony/console是瓶颈，当前装的是v5.4.42，而目标框架要^6.4，运行：composer update symfony/console --with-dependencies - 若某个第三方包（如
spatie/laravel-backup）死守旧版约束，暂时无法升级，就显式降级它："spatie/laravel-backup": "6.12.0"，改完立刻composer update spatie/laravel-backup --with-dependencies - 开发依赖（如
phpunit/phpunit）常拖累生产依赖，可临时屏蔽："config": {"platform": {"phpunit/phpunit": "9.6.13"}}加到composer.json的config段里
慎用 --no-update 和 replace
手动干预版本时，--no-update 是安全边界：
- 想强制拉取兼容版？用
composer require symfony/console:^5.4 --no-update—— 只改composer.json，不立刻重算，避免中途中断 - 改完再跑
composer update symfony/console，让 Composer 仅针对该包重新解析 -
replace不是“绕过检查”的快捷键，它是告诉 Composer “这个包已被另一个完全替代”，一旦误配，运行时可能直接类找不到；除非你确认两个包 ABI 兼容，否则别碰
最常被忽略的点：冲突往往藏在 require-dev 里，或者由 platform 配置和本地 PHP 版本不一致引发。别只盯着报错第一行，得一层层剥开依赖树看谁在真正卡路。
