--force-reinstall --no-cache 是最接近“强制刷新”的组合：它强制覆盖重写 vendor 中所有包并禁用缓存，确保完全重新下载、解压、安装，缺一不可。
composer install --force-reinstall --no-cache 是最接近“强制刷新”的组合
Composer 没有 reinstall 或 refresh 命令，所谓“强制刷新依赖”，本质是让每个包都重新下载、解压、安装，不复用缓存、不跳过已存在文件。从 Composer 2.2 起，--force-reinstall 参数才真正生效——它会覆盖 vendor 中已存在的包目录；而 --no-cache 则确保不从 ~/.composer/cache 拉 ZIP 或 Git 快照。两者缺一不可。
-
composer install --force-reinstall：重装但可能仍走缓存（尤其旧版 Composer） -
composer install --no-cache：跳过缓存，但若 vendor 目录里文件完好，它可能直接跳过解压 -
composer install --force-reinstall --no-cache：既清缓存路径，又强制覆盖重写，才是可靠刷新
删 vendor + 保留 composer.lock 是日常维护最稳的做法
很多团队误以为“删 lock 才算干净”，其实恰恰相反：只要 composer.lock 是你确认过、提交到 Git 的版本，只删 vendor/ 再运行 composer install，就能 100% 复现线上环境。这比删 lock 后重生成更安全，避免因依赖解析波动引入意外版本。
- Windows 用户注意：
rm -rf vendor在 CMD 不生效，推荐用 PowerShell：Remove-Item -Recurse -Force vendor - 如果执行时报
Permission denied，大概率是 IDE（如 PhpStorm）或 PHP 进程（如 Swoole Worker）锁住了子目录，需先关闭再删 - 删完不要急着
composer update——那是升级逻辑，不是刷新逻辑；必须用install
为什么 clear-cache 单独用没用？
composer clear-cache 只清全局缓存，不影响 vendor 目录内容，也不影响 Composer 对“文件已存在”的判断。即使缓存清空了，composer install 仍会检查 vendor/autoload.php 是否存在、是否可加载，然后直接跳过安装步骤。所以常见错误是：“我明明清了缓存，vendor 里某个类还是报错”——问题不在缓存，而在 vendor 本身损坏或 autoload 映射失效。
- 验证是否真刷新成功：检查
vendor/package-name/下的文件修改时间是否为当前秒级时间戳 - 若仍有 autoload 问题，补跑：
composer dump-autoload -o - 某些包（如 Laravel 的
phpunit/phpunit）含 bin 脚本，删 vendor 后要确认vendor/bin/phpunit是否重建
想更新单个包？别用 install，用 update + 精确包名
很多人试图通过删 vendor + 修改 composer.json + install 来“强制更新某一个包”，这是绕远路。正确做法是：composer update vendor/package-name。它只解析该包及其必要子依赖，不会动其他 require 项，且全程受 composer.lock 约束保护。
- 例如更新
monolog/monolog：composer update monolog/monolog - 若它依赖的
psr/log也需要同步升版，加--with-dependencies： composer update monolog/monolog --with-dependencies- 切忌在生产环境用
--no-lock，它跳过 lock 文件写入，会导致协作时依赖树不一致
真正麻烦的从来不是命令记不住，而是分不清“重装”“升级”“刷新”三者的边界——删 vendor 是重装，update 是升级，--force-reinstall --no-cache 才是刷新。选错动作，轻则白忙，重则上线翻车。
