安全降级需先查依赖再操作：第一步用composer depends和show -t定位约束；第二步删lock后install回退；第三步改json并update --with-all-dependencies。
直接降级不安全，必须先确认冲突根源再操作；盲目 composer require 指定旧版本可能引发隐式依赖断裂。
为什么 composer require vendor/package:1.2.0 常常失败
Composer 不是“覆盖安装”，而是求解整个依赖图的满足解。指定一个旧版本后，若其他已装包（比如 laravel/framework 或 symfony/console）在 composer.lock 中锁定了要求更高版本的子依赖，Composer 就会拒绝降级——报错通常是 Your requirements could not be resolved。
- 错误现象：
Root composer.json requires vendor/package ^1.5.0, found vendor/package[1.2.0] but the package is fixed to 1.8.3 (lock file version) by a partial update. - 根本原因：锁文件里已有约束，且未用
--with-all-dependencies显式放开传递依赖限制 - 正确做法：先
composer show vendor/package看当前实际安装版本和允许范围，再决定是否需先composer update --dry-run验证可行性
安全降级三步法：从查依赖到写命令
目标不是“把 A 包改成旧版”，而是“让 A 包及其所有上游/下游依赖共同退到一组兼容快照”。这必须靠 Composer 自身的解依赖机制，不能硬覆盖。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 第一步：查清当前约束来源 —— 运行
composer depends vendor/package，看谁在依赖它；再运行composer show -t vendor/package查它自己依赖了哪些包（避免降级后触发其子依赖不兼容） - 第二步：临时放宽锁定 —— 删除
composer.lock文件（或备份后删），再执行composer install --no-scripts回滚到composer.json声明的版本范围（注意：这仅适用于你明确知道composer.json里写的版本是旧的） - 第三步：精准锁定旧版并重算 —— 改
composer.json中对应行，如"vendor/package": "1.2.0"（带引号、无^），然后运行composer update vendor/package --with-all-dependencies
遇到 conflict 报错时该盯哪几个地方
Composer 冲突提示往往藏关键线索，别只看第一行。重点扫视以下三类信息：
- 报错中反复出现的包名，比如
phpunit/phpunit和myclabs/deep-copy同时被提及 → 很可能是 PHPUnit 的某个小版本强制要求 deep-copy ≥1.10，而你想降的包依赖的是 ≤1.7 -
Root requirements下列出的版本范围，确认你写的"vendor/package": "1.2.0"是否被识别为1.2.0.0（Composer 会补零），有时1.2和1.2.0在解析上行为不同 - PHP 版本兼容线：运行
composer config platform.php看是否人为锁定了 PHP 版本，某些旧包（如guzzlehttp/guzzle:6.5）不支持 PHP 8.2，但锁了"platform": {"php": "8.2"}就会让降级失败
真正麻烦的从来不是“怎么输命令”，而是搞清哪个间接依赖在卡脖子——composer why-not 和 composer prohibits 这两个命令得翻来覆去跑几遍，不然很容易在 vendor/ 里手动删包，结果下次 composer install 又拉回来。
