直接删 vendor 目录并运行 composer install 才是重装依赖的可靠做法；composer update 会重新解析版本约束，导致升级、降级或换包，行为不可控。
直接删 vendor 目录 + 运行 composer install，才是重装所有依赖的可靠做法；composer update 不是重装，它会按 composer.json 重新解析版本约束，可能升级、降级甚至换包，行为不可控。
为什么不能只用 composer update
composer update 读的是 composer.json，不是 composer.lock。它会重新走一遍依赖求解器，结果取决于当前仓库的包版本状态、平台配置（如 PHP 版本）、以及是否加了 --with-all-dependencies 等参数。常见问题包括：
- 本地
composer.lock里锁着 v2.1.0 的monolog/monolog，但运行composer update后变成 v3.0.0（因 v3 已发布且满足"monolog/monolog": "^2.0"） - 团队成员 PHP 版本不一致，有人跑
update后引入了仅支持 PHP 8.2 的新依赖，CI 构建失败 - 没加
--no-dev，开发依赖也被更新，导致生产环境意外加载了phpunit类文件
真正“重装”的标准流程
目标是彻底还原到 composer.lock 所声明的状态，和 CI 或生产环境保持一致。操作分三步，缺一不可：
- 删除
vendor目录：rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows） - 确认
composer.lock存在且未被修改（git status检查） - 执行
composer install（不是update），它会严格按lock文件安装每个包的精确版本和哈希
如果 composer.lock 丢失或损坏，先用 composer update --lock 生成一份最小可用 lock 文件，再走上面三步。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
什么时候该用 composer update
只有明确需要变更依赖版本时才用，比如：
- 升级某个包到新版修复安全漏洞：
composer update vendor/package-name - 同步
composer.json新增的 require 项：composer update --with-dependencies - 临时调试兼容性问题，需强制刷新整个依赖图：
composer update --ignore-platform-reqs（仅调试，勿提交）
注意：composer update 一定会改写 composer.lock，提交前务必确认 diff 是你预期的。
常见卡点与绕过方式
重装过程中最常遇到两类阻塞：
-
PHP version x.y.z does not satisfy requirement：检查composer.json中config.platform.php是否设错，或本地 PHP 版本低于composer.lock所需最低版本 -
Failed to download vendor/package: file could not be downloaded (HTTP 404)：可能是 packagist 镜像失效，临时切回官方源：composer config -g repo.packagist composer https://packagist.org - Windows 下提示
Operation not permitted：关闭杀毒软件实时扫描，或用管理员权限运行终端
重装的本质是“信任 lock 文件”，而不是让 Composer 再猜一次该装什么。只要 lock 文件干净，install 就是最稳的路径。
