删 vendor 目录只是放弃当前依赖状态的最后手段，仅在锁文件失效、环境污染且所有解析路径堵死时才适用；必须同步删除 composer.lock、清缓存、校验 platform 配置，并用 --no-cache 重装。
删除 vendor 目录本身不是解法，而是放弃当前依赖状态的最后手段——它只在「锁文件已失效 + 本地环境已污染 + 所有解析路径都被堵死」时才值得考虑。
为什么 composer install 会失败，但删了 vendor 也不一定好使
很多人删完 vendor 立刻跑 composer install，结果还是报错，甚至更糟。原因很实在：
-
composer.lock仍是旧的，里面记录的哈希、源地址、嵌套依赖拓扑可能已和 Packagist 当前状态不一致（比如某个间接依赖被作者删了 tag） - 本地
~/.composer/cache里缓存了损坏的 dist 包或元数据，install会优先复用，直接复现失败 - PHP 版本、扩展（如
ext-zip）、platform配置和 lock 文件生成时不同，导致解析器选了另一条失败路径
composer update --lock 失效时，才轮到删 vendor
真正该先试的永远是 composer update --lock：它不动包、不联网、不改 vendor，只刷新 lock 文件结构。如果这步都失败（比如报 cycle detected 或 content-hash mismatch），说明依赖图本身已无法自洽。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
这时再删 vendor 才有意义，但必须连带清理配套状态：
- 删掉
vendor/和composer.lock（二者必须一起删，单删 vendor 没用） - 清空 Composer 全局缓存：
composer clear-cache - 确认
composer.json中config.platform和你当前 PHP 版本一致（比如 PHP 8.3 就别留"php": "7.4"） - 再跑
composer install --no-cache，强制跳过本地缓存，从源重新拉取
删 vendor 后仍失败？检查三个隐性污染点
删了重装还卡住，大概率是环境残留干扰了依赖解析：
-
require-dev里的包悄悄引入冲突：比如phpunit/phpunit拉了symfony/console:^5，而主项目要^6—— 这类问题在--dry-run日志里会反复出现Trying symfony/console[5.4.0]然后回退 - 项目根目录下有
composer.json的 Git merge conflict 标记（），Composer 会直接 parse 失败，报错却不说哪行 - 某些 IDE（如 PHPStorm）或 CI 工具在后台偷偷运行了
composer dump-autoload，生成了损坏的vendor/composer/autoload_*.php，删vendor后没清干净
最常被忽略的是：删 vendor 只解决「已安装内容」，不解决「约束逻辑错误」。如果 composer.json 里同时写了 "monolog/monolog": "^1.25" 和 "laravel/framework": "^10.0"（后者要求 monolog:^3.0），删多少遍 vendor 都没用——得先用 composer why-not monolog/monolog:^3.0 把这个矛盾挖出来。
