composer install --force-reinstall是唯一合法且有效的强制重装命令，它不删vendor、不动composer.lock，仅逐个删除包目录→重新下载解压→覆盖写入→重建autoload→重跑post-install-cmd。
直接用 composer install --force-reinstall，这是唯一合法、可复现、不破坏环境一致性的强制重装方式。
为什么 composer install --force 会报错
Composer 没有 --force 这个参数。输错后终端会明确提示 Unrecognized option "--force"。真正起效的是 --force-reinstall，它从 Composer 2.2 起稳定支持，语义清晰：不删 vendor/、不动 composer.lock，只对每个已安装包执行“删目录 → 下载解压 → 写入 → 重建 autoload → 重跑 post-install-cmd”。
-
composer install --force-reinstall不触发依赖解析，版本完全按 lock 文件锁定 - 它比
rm -rf vendor && composer install更快：autoload 映射结构不用全量重建，未变的 dist 包还能复用缓存 - Windows 下若卡在
Could not delete: Permission denied，先关掉 PhpStorm、Xdebug 或其他占用 PHP 进程的工具再执行
composer install 为什么不重装已存在的包
因为它的设计语义就是“按 composer.lock 复原”，不是“重装”。哪怕你手动删空了 vendor/，只要 composer.lock 还在，Composer 就只从本地缓存（~/.composer/cache/）解压旧 ZIP，甚至不发网络请求。
- 典型现象：终端输出飞快、看不到
Downloading、文件时间戳没变、校验失败报Invalid zip file - 只删
vendor/→ 仍是复原 - 只删
composer.lock不清缓存 → 可能复用旧 ZIP，连网络都不走 - 真正触发全新拉取的唯一组合是：
rm -rf vendor composer.lock && composer clear-cache && composer install --no-cache
想按 composer.json 重新算依赖，该用哪个命令
必须用 composer update。删掉 composer.lock 后，composer install 会直接报错：Lock file does not exist. Run composer update to create it.
-
composer update才会读composer.json、调用 SAT 求解器、生成新 lock、决定每个包的最终版本 - 加
--with-all-dependencies才能确保间接依赖（比如被laravel/frameworkrequire 的symfony/http-foundation）也被纳入求解范围 - 线上环境慎用：它可能升级大版本（如 Laravel 9 → 10），引入不兼容变更
- 只想升一个包？用
composer update guzzlehttp/guzzle --with-dependencies更安全
本地 path 仓库不生效，怎么强制切换
Composer 默认只在首次安装或锁文件缺失时读取 repositories 配置；如果已有 composer.lock，它会照着锁文件还原，完全忽略新配的 path 仓库。
- 必须删掉
composer.lock和vendor/目录 - 确认
repositories在项目根目录composer.json的顶层字段，不能嵌在require或config里 -
url必须是相对路径（如../mylib），不能以/开头，否则 Windows 下解析失败 -
require中的包名（如myvendor/mylib）必须与本地库composer.json中的"name"完全一致（含大小写） - 运行
composer install（不是update），它会重新解析composer.json并生成新 lock 文件
最容易被忽略的一点是：Windows 下符号链接常因权限限制失效，vendor/myvendor/mylib 可能是真实复制的目录而非链接——此时改了本地库代码，主项目根本不会感知变化。检查该路径是否为软链接（Linux/macOS）或目录交接（Windows），才能确认 path 是否真正在工作。
