最彻底可控的依赖重装方式是先删除 vendor 目录再执行 composer install。该操作确保所有包严格按 composer.lock 精确还原，避免 composer update 因依赖解析导致的版本偏差或残留文件问题。
直接删 vendor 目录再 composer install
这是最彻底、最可控的方式。Composer 没有“强制重装全部依赖”的原子命令，composer update 会走依赖解析和版本策略，可能跳过某些包；而手动清空 vendor 后重装，等于从零构建，确保所有包都按 composer.lock 精确还原。
常见错误现象：composer update --force 或 --with-all-dependencies 并不能清掉已安装但未被锁文件记录的残留文件（比如被手动改过的包、dev-only 包残留、或因中断导致的半安装状态）。
- 先运行
rm -rf vendor（Linux/macOS）或rmdir /s vendor（Windows cmd），确认目录为空 - 确保
composer.lock文件存在且是你想还原的版本 —— 它才是重装的唯一依据 - 执行
composer install，不是update；后者会重新解析依赖树，可能升级小版本甚至引入不兼容变更 - 如果项目用到
platform-check或 PHP 扩展约束，注意当前环境要满足composer.json中的config.platform声明，否则会跳过部分包
composer install 失败时，先检查 composer.lock 是否可信
很多“重装失败”其实源于 composer.lock 本身已损坏或与 composer.json 不一致。Composer 在 install 时只校验 lock 文件完整性，不反向验证其是否由当前 json 生成。
使用场景：CI/CD 流水线中反复失败、本地换 PHP 版本后安装报错、团队协作中 lock 文件被意外修改。
- 运行
composer validate，看是否提示 “lock file is not up to date with composer.json” - 若提示不一致，别急着删 vendor，先跑
composer update --lock仅更新 lock 文件（不碰 vendor），再重试 install - 如果 lock 文件是别人提交的，且你不确定它是否经过完整测试，建议先
git checkout origin/main -- composer.lock拉取权威版本
想跳过 autoload 生成或脚本执行？用 --no-autoloader 和 --no-scripts
重装过程中最耗时的环节往往是自动生成 autoload 文件和执行 post-install-cmd 脚本（比如生成配置、清理缓存）。调试阶段不需要这些，可跳过加速验证。
性能影响：在大型项目中，关闭 autoload 可节省 2–5 秒；禁用 scripts 能避免因环境缺失导致的中断（比如没装 npm 却要跑 npm run build）。
-
composer install --no-autoloader --no-scripts适合快速验证依赖结构是否正常 - 之后补上
composer dump-autoload即可恢复自动加载 - 注意：
--no-scripts会跳过post-install-cmd，但不会跳过pre-install-cmd—— 后者仍会执行，如有副作用需提前评估
Windows 下权限残留导致删不干净 vendor
Windows 资源管理器或某些 IDE（如 PHPStorm）会持有 vendor 子目录句柄，导致 rmdir /s vendor 报 “拒绝访问” 或静默失败，后续 install 出现文件冲突或跳过写入。
容易踩的坑：用 Git Bash 或 WSL 运行 rm -rf vendor 看似成功，但 Windows 主机层文件句柄未释放，实际文件仍在占用。
- 关掉所有 IDE、终端、文件管理器窗口，尤其是打开过
vendor内任意文件的程序 - 用 PowerShell 运行：
Remove-Item -Path "./vendor" -Recurse -Force，比 cmd 更可靠 - 实在删不掉？重启终端或系统，再试 —— 别用
composer update强行覆盖，那只会掩盖问题
事情说清了就结束。真正麻烦的不是命令怎么敲，而是删 vendor 前没确认 lock 文件是否干净，以及删完没关掉盯着 vendor 的进程。
