composer降级失败是因为依赖图中存在不兼容约束，需用composer why-not查拦截项、composer show验证版本可用性，并显式锁定版本后加--with-dependencies重算依赖。
降级不是“回退一个版本号”就能成的事——Composer 会重新解整个依赖图，只要某条路径上存在无法向下兼容的约束，它就会直接拒绝，而不是帮你找“最接近的旧版”。
composer update vendor/package:1.2.3 为什么失败？
这不是命令写错了，而是 Composer 在执行时发现：你指定的 1.2.3 虽然满足你 composer.json 里的约束（比如 "^1.0"），但某个已安装的依赖（比如 acme/utils）在它的 composer.json 中写了 "require": {"vendor/package": "^1.5"}，这就把 1.2.3 排除在外了。
常见错误现象：
- 报错末尾出现
Conclusion: don't install vendor/package 1.2.3，但前面没说谁拦的 - 运行
composer update vendor/package:1.2.3 --dry-run -v后，在日志里反复看到Trying vendor/package 1.2.3→Reverting→Backtracking
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先跑
composer why-not vendor/package:1.2.3，它会明确列出所有封杀该版本的包和它们的约束条件 - 再用
composer show vendor/package 1.2.3看这个版本实际 require 哪些包，确认它是否真能被当前环境“接受” - 别直接改
composer.lock手动降级——Composer 下次install或update仍会校验并报错
如何安全地把一个包从 v2.x 降到 v1.x？
跨主版本降级本质是切换依赖契约，风险远高于小版本更新。Composer 不会自动处理 API 断裂，它只管约束是否可满足。
使用场景：你依赖的 guzzlehttp/guzzle 升到了 ^8.0，但某私有 SDK 只支持 ^7.0，你想临时切回 7.4.5 维持上线。
实操建议：
- 先确认
7.4.5是否还在 Packagist 上可用（有些老版本会被标记为abandoned） - 在
composer.json中显式锁定："guzzlehttp/guzzle": "7.4.5"，而非"^7.0"—— 避免 Composer 自行选到不兼容的7.9.0 - 执行
composer update guzzlehttp/guzzle --with-dependencies，强制重算其子依赖（如psr/http-client、ralouphie/getallheaders） - 检查
composer show --tree guzzlehttp/guzzle，确认没有 dev-only 包（如phpunit/phpunit）偷偷拉入^8.0的传递依赖
降级后运行时报 Class not found 或 Method not exists 怎么办？
这说明 Composer 成功装上了旧版，但你的代码或某个依赖仍在调用新版才有的类或方法——Composer 解决的是“能不能装”，不是“能不能跑”。
典型原因：
- 你自己的代码用了
GuzzleHttp\Client::sendAsync()（v8 新增），但降级到 v7 后该方法不存在 - 某个依赖（如
spatie/laravel-backup）在 v8 下才支持 Laravel 11，你强行降级 Guzzle 却没同步降级它，导致它内部调用失败 -
require-dev里的测试工具（如pestphp/pest）悄悄要求了新版symfony/console，而它又通过 PSR-18 抽象间接依赖 Guzzle，形成隐式冲突链
实操建议：
- 搜索项目代码中对目标包的调用：
grep -r "sendAsync\|new Client" app/ tests/ --include="*.php" - 运行
composer depends guzzlehttp/guzzle查哪些包直接依赖它；再跑composer prohibits guzzlehttp/guzzle:^8.0看谁在明令禁止 v8 - 如果只是临时调试，加
"minimum-stability": "stable"和"prefer-stable": true到composer.json，避免 dev 分支搅局
为什么删了 composer.lock 再 install 还是装不上旧版？
因为 composer.lock 只记录“上次成功解出的版本组合”，不是“唯一可行组合”。删掉它只是让 Composer 重新跑一遍 SAT 求解器，而求解逻辑没变——只要约束没改，它大概率还会选出同一个“最优解”（通常是最新兼容版）。
容易踩的坑：
- 以为
composer install会尊重composer.json里写的"^1.0"就一定装1.x，其实它可能选2.0.0（如果所有依赖都同意） - 在 CI 中用
--no-dev安装，本地却保留require-dev，导致本地能装、CI 报错——因为 dev 包的依赖树也被纳入了求解范围 - 忽略
conflict字段：某个包写了"conflict": {"guzzlehttp/guzzle": ">=8.0"}，哪怕你没 require 它，只要其他包间接拉进来，就会触发全局拦截
真正可控的方式只有两个：显式锁定版本号（如 "7.4.5"），或修改约束本身（如把 "^7.0 || ^8.0" 改成 "^7.0" 并确保所有依赖都松动）。其他都是掩耳盗铃。
