最干净的重装方式是删 vendor 目录和 composer.lock 后执行 composer install，因 install 会严格按 composer.json 生成新锁并精准重建依赖；而 update 会重算依赖树，导致版本漂移。
直接删 vendor 目录 + 清空 composer.lock 是最干净的重装方式，但必须配合 composer install（而非 composer update）才能真正还原原始依赖状态。
为什么不能只删 vendor 目录？
删掉 vendor 后如果直接运行 composer update，Composer 会按当前 composer.json 中的版本约束重新解析依赖树，可能拉取新版包、触发兼容性变更，甚至引入意外的次要版本更新。而项目原本能跑，往往依赖的是 composer.lock 锁定的具体提交或版本号。
-
composer.lock记录了每包的确切版本、hash、require 关系，是可复现安装的唯一依据 - 仅删
vendor保留composer.lock→composer install可精准重建 - 删
vendor+ 删composer.lock→composer install会失败（因无锁文件），必须用composer update生成新锁，但这就不是“还原”而是“重算”了
真正干净重装的三步操作
适用于：CI 构建、协作环境初始化、怀疑本地 vendor 污染或损坏时。
- 执行
rm -rf vendor composer.lock（Linux/macOS）或rd /s /q vendor && del composer.lock（Windows） - 确认
composer.json是你想要的基准（比如从 Git 拉取最新、或已手动修正） - 运行
composer install --no-dev（如需生产环境）或composer install（含 dev 依赖）——注意，这里必须是install，它会自动生成新composer.lock并严格按当前composer.json解析一次
composer update 和 composer install 的本质区别
很多人混淆二者行为，导致重装后行为不一致：
-
composer install：有composer.lock就照着装；没锁文件就先解析composer.json生成锁，再装 —— 这个“生成锁”的过程等价于一次最小化update，但不会升级已有包（因无旧锁可比） -
composer update：强制丢弃composer.lock当前内容，重新解析所有依赖约束，可能升/降级任意包，哪怕只是小版本（如"monolog/monolog": "^2.0"可能装 2.10.0 而非 2.8.0） - 所以“清理后重装”场景下，
install更可控；只有明确要升级依赖时才用update
额外提醒：缓存和全局配置的影响
即使 vendor 和 lock 都清了，Composer 本地缓存（~/.composer/cache）可能让某些包跳过校验直接解压，导致看似重装实则复用旧文件。遇到诡异行为时：
- 加
--no-cache参数：例如composer install --no-cache - 或手动清缓存：
composer clear-cache - 检查是否启用了
COMPOSER_HOME或COMPOSER_CACHE_DIR环境变量，避免跨项目污染
真正“干净”的起点，是删 vendor、删 lock、清缓存、确认 composer.json 正确——四者缺一不可。尤其在调试 autoload 失败或 class not found 时，漏掉缓存这步，问题很可能原样复现。
