Composer 没有 reinstall 命令，因其设计遵循“按锁还原”原则，依赖 composer.lock 精确重建环境；真要修复单个包需手动清理缓存与 vendor 目录后执行 composer install --no-cache。
Composer 没有 reinstall 命令——它根本不存在。所有声称“用 composer reinstall 修复依赖”的说法，都是对 Composer 工作机制的误解。
为什么找不到 composer reinstall？
Composer 的命令列表里从没定义过 reinstall。运行 composer list 或查官方文档，都找不到这个子命令。它不是被隐藏、没启用，而是压根没实现。Composer 的设计哲学是“按锁还原”，不是“覆盖重装”：它靠 composer.lock 精确控制版本，靠 composer install 重建环境，靠 composer update 重新计算依赖——没有“重装当前包”这种中间态操作。
composer update vendor/package 不等于重装
很多人以为执行 composer update monolog/monolog 就是“只重装 monolog”，实际不是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 它只更新
monolog/monolog的顶层版本，不触及其子依赖（比如psr/log），容易导致运行时Class not found - 如果
composer.lock里该包是通过dev-master+ commit hash 锁定的，update可能拉新 commit，但不会校验旧 vendor 是否残留冲突文件 - 它仍会读缓存、走镜像、尝试 dist 下载——若缓存损坏或镜像滞后，照样报
checksum mismatch
真要“快速修复单个包”，得绕开 update
当某个包（如 guzzlehttp/guzzle）反复报 Failed to extract 或 corrupted zip file，但其他包正常，说明问题局限在缓存或 vendor 子目录。这时比 update 更准、更快的做法是：
- 删掉对应缓存：
rm -rf ~/.composer/cache/files/guzzlehttp/guzzle（Linux/macOS）或进%APPDATA%\Composer\Cache\files\手动清理 - 删干净 vendor 里的目标包：
rm -rf vendor/guzzlehttp（别只删vendor/guzzlehttp/guzzle，要删整个命名空间目录） - 强制跳过缓存重装：
composer install --no-cache --no-dev（加--no-dev防止意外装入 dev-only 包） - 若仍失败，临时切回官方源保真：
composer config -g --unset repos.packagist && composer clear-cache，再重试
真正需要“彻底重来”的信号
以下情况，别折腾单包修复，直接双清（vendor + composer.lock）再 install：
- 多个包同时报哈希不匹配（
checksum mismatch） -
composer validate提示./composer.lock is invalid（JSON 解析失败） - 运行时大量
Class not found，但vendor/autoload.php存在且路径正确 - CI 流水线中不同机器装出不同版本，怀疑
composer.lock被 Git 换行符或合并冲突污染
最容易被忽略的是：缓存目录里的 repo/ 子目录会固化旧镜像返回的元数据，哪怕你已切到阿里云源，不清缓存就永远读不到新包列表——这不是命令缺失的问题，是状态残留的惯性。
