删 composer.lock 后执行 composer install 会报错，因其依赖锁文件存在；正确做法是删 composer.lock 后运行 composer update，或仅删 vendor 后用 composer install 修复目录。
删 composer.lock 后用 composer install 是错的
直接删掉 composer.lock 再跑 composer install，根本不会“重新安装”，而是报错：Lock file does not contain required package "xxx" 或直接拒绝执行——因为 composer install 的前提就是 composer.lock 存在且与 composer.json 兼容。删了锁文件却还用 install，就像拿空地图问路。
- 真正触发“按
composer.json重算依赖”的命令是composer update，不是install -
composer update会读composer.json的版本约束，重新解析整个依赖树，生成新composer.lock - 如果只是想修复损坏的
vendor/目录（比如文件缺失、符号链接断裂），保留composer.lock，只删vendor，再composer install就够了
彻底重置依赖：删 composer.lock + composer update
这才是“强制按最新规则重装所有包”的标准动作。它等价于把旧依赖图完全扔掉，从头开始求解兼容版本组合。
- 先执行：
rm composer.lock && rm -rf vendor - 再执行：
composer update（不加任何参数） - 该操作会忽略旧锁文件，严格依据
composer.json中的require和平台配置（如 PHP 版本）重新计算 - 若项目中
"php": "^8.1"，但你本地是 PHP 8.0，会报错；此时可临时加--ignore-platform-reqs，但上线前必须修正环境
为什么不能跳过 composer.lock 直接 composer install？
因为 composer.lock 不是可选日志，它是生产一致性的唯一凭证。没有它，composer install 失去依据，无法运行。
- Git 提交时漏掉
composer.lock→ 团队其他人composer install直接失败 - 误编辑了
composer.lock导致 JSON 格式错误 →composer install报JSON decode error - CI 流水线用了 Composer 2.x，但本地是 1.x，而
composer.lock是 1.x 生成的 → 安装时提示lock file is not compatible with this version of Composer
遇到这类问题，不要硬删锁文件，应先备份，再运行 composer update --lock：它只升级锁文件结构（如补全 plugin-api-version 字段），不改动任何包版本。
Windows 下删 vendor 经常失败？关键在释放句柄
不是命令不对，是 Windows 不允许删除被占用的目录。IDE（如 PhpStorm）、调试器（Xdebug）、常驻进程（Swoole、Laravel Octane）都会锁住 vendor/bin 或子文件夹。
- 关掉所有 PHP 进程：
taskkill /F /IM php.exe - 退出 IDE，或禁用其“索引”和“实时检查”功能
- 用 PowerShell 执行：
Remove-Item -Recurse -Force vendor（比 CMD 的rd /s /q vendor更可靠） - 删完若
composer install报Permission denied，说明还有残留句柄，重启终端再试
最易被忽略的点：删 vendor 前没确认 composer.lock 是否是你真想要的那个版本——它可能早被别人改过、没提交、甚至被 Git 忽略了。动手前先 git status 看一眼。
