删 composer.lock 是最危险操作，真正应删的是 config.platform.php 中不兼容的 php 版本声明；降级失败常因 platform 拦截而非依赖冲突，需先检查并临时移除 platform 配置，再用 composer require --with-all-dependencies 重算依赖，最后执行 composer dump-autoload 清除 autoload 缓存。
删 composer.lock 是最危险的操作，不是解法，而是最后手段；真正该删的，是 config.platform.php 里不兼容的 PHP 版本声明，或临时移除锁死子依赖的插件配置。
composer update vendor/package 不生效，先盯 config.platform.php
很多降级失败根本没走到依赖冲突那步，而是被 config.platform.php 静默拦截了。比如你项目里写了 "php": "8.2"，但想降的包只支持 ^7.4 || ^8.0，Composer 就会跳过它，不报错、不提示、也不更新 lock 文件。
- 临时删掉
config.platform.php段，再试一次composer require vendor/package:1.2.3 --with-all-dependencies - 如果成功，说明问题出在平台声明上——要么改低 PHP 版本，要么换一个兼容 8.2 的旧版（查
composer show -a vendor/package看哪些 tag 标了php: >=8.2） - 别长期保留
config.platform.php，它会让本地开发和 CI 环境行为不一致
报 Your requirements could not be resolved，别急着删 lock 文件
这个错误本质是 Composer 在求解整棵树时发现无解，不是某个文件坏了。删 composer.lock 只会让问题更模糊：它可能装回一个你根本没测试过的组合，甚至触发 autoload 错误。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先跑
composer why-not vendor/package:1.2.3，它会直接告诉你哪个包（比如laravel/framework）强制要求子依赖 ≥2.0 - 再跑
composer depends vendor/package，看谁在顶层强依赖它；如果只有测试工具（如phpunit/phpunit）在用，可以考虑require-dev单独处理 - 若确认必须降，就用
--with-all-dependencies让 Composer 主动放宽其他包的约束，而不是手动删 lock
降级后 Class not found，90% 是 autoload 缓存没清
执行完 composer require，composer show 显示版本对了，vendor 目录里也看到对应 tag 的文件，但运行时报 Class 'X' not found——这不是包没装上，是自动加载映射还指着旧版的 classmap 或 PSR-4 路径。
- 立刻执行
composer dump-autoload，强制重建映射 - 如果项目用了
"classmap": ["src/"]，加-o参数：composer dump-autoload -o - PHP-FPM 环境下，还得
sudo systemctl reload php*-fpm或重启服务，否则 opcache 会缓存旧的 autoloader
真正麻烦的从来不是命令怎么写，而是降级后那一堆隐式依赖的兼容性断点——它们不会报错，只会让某个边缘功能突然失效。每次降级完，别只跑 composer show，得真调一次相关接口或命令，看逻辑是否走通。
