composer install --force-reinstall 是最直接的覆盖安装方式，它强制按 composer.lock 重装所有包，覆盖文件、重建 autoload、重跑 post-install-cmd 脚本，不删 vendor、不改 lock，确保可复现。
composer install --force-reinstall 是最直接的覆盖安装方式
想不动 vendor 目录、不删 composer.lock，但让所有包重新下载解压并执行安装脚本？composer install --force-reinstall 就是专为这个场景设计的命令。它跳过“已存在则跳过”的校验逻辑，强制按 composer.lock 重装每一个包——文件被覆盖、autoload 重建、post-install-cmd 脚本也会再跑一遍。
- 比
rm -rf vendor && composer install更快：避免重复解压和反复触发脚本 - 保留
composer.lock不变，确保结果可复现，适合 CI/CD 中修复偶发损坏 - 若只装生产环境依赖，加
--no-dev；若某些间接依赖没被覆盖，可加--with-all-dependencies - ⚠️ 前提是
composer.lock已是最新的——如果composer.json改了但 lock 没同步，先运行composer update --lock-only
Windows 下文件被占用导致覆盖失败怎么办
在 Windows 上，composer install --force-reinstall 可能中途报错，比如 Permission denied 或 Could not delete ...，常见原因是 PHP 进程（如 Swoole、Xdebug）、IDE（如 PhpStorm 的索引服务）或终端本身正占用 vendor 下某个子目录或文件。
- 关掉所有正在运行的 PHP 服务、调试器、Web 服务器（如 Laravel Sail、Valet）
- 退出 IDE，或在 PhpStorm 中禁用 “Synchronize files on frame activation”
- 用 PowerShell 执行清理：
Remove-Item -Recurse -Force vendor\some-package，避开全局删除 - 仍失败？重启终端（CMD/PowerShell），再试；或临时加
--prefer-dist减少对符号链接的依赖（因 Windows 默认禁用 symlinks）
为什么不用 composer update 来“重装”
composer update 的本质是重新解析依赖树、升级到符合约束的最新版本，不是重装。它会改 composer.lock，可能引入不兼容变更，甚至跳过你本想“强制刷新”的包。
- 现象：运行
composer update guzzlehttp/guzzle后，vendor/guzzlehttp/guzzle版本变了，但vendor/psr/http-client没更新，autoload 也没重建 → 不是你想要的“覆盖安装” - 对比：
composer install --force-reinstall严格按 lock 文件来，版本、路径、脚本全部对齐 - 例外场景：你确实想升版 + 重装，那才该用
composer update --with-all-dependencies，但必须清楚这是语义不同的操作
覆盖安装后还报错？检查 autoload 和脚本是否真执行了
很多“重装无效”的问题，其实不是包没换，而是自动加载映射没刷新，或者 post-install-cmd（比如 Laravel\framework 的 storage:link）根本没重跑。
- 手动重建 autoload：
composer dump-autoload -o - 手动触发安装后脚本：
composer run-script post-install-cmd - 确认实际加载版本：
composer show --tree | head -n 20，看输出是否与composer.lock一致 - 若怀疑缓存干扰，可加
--no-cache参数（Composer 2.5+），或先composer clear-cache
--force-reinstall 对 composer.lock 的强依赖——它不会帮你纠错，只会忠实地把 lock 里的内容再铺一遍。 
