删 vendor 后不能直接重试 install，因 composer 检测到 vendor 目录非空即进入增量更新模式，跳过缺失包且不报错；必须彻底清空 vendor、清理缓存与 opcache，并确认 composer.lock 完整后，再执行 composer install 才能完整重建。
删 vendor 失败或安装中断后，不能靠 composer update 或重试 composer install 来“修好”，必须先清理残留、确认锁文件状态，再用 composer install 重建 —— 否则大概率装出混合版本或跳过缺失包。
删 vendor 目录失败时，为什么不能直接重试 install？
Windows 下用资源管理器手动删 vendor 常卡住，报 Permission denied；Linux/macOS 用 rm -rf 中断后，vendor 可能只剩空目录或残留子文件夹（如 vendor/autoload.php 还在，但 vendor/myorg/mylib 已毁）。这时 composer install 不会走完整流程，而是进入“增量更新”模式 —— 它只检查已存在包的版本是否匹配 composer.lock，对缺失的包直接跳过，不补、不报错、也不提示。
- 现象：运行
composer install后命令快速退出，没报错，但vendor/myorg/mylib就是没回来 - 原因：Composer 认为“目录存在 = 包已安装”，哪怕里面只剩一个空
composer/子目录 - 验证方式：执行
ls -la vendor/，只要输出非空，就不是“完全清空”状态
中断安装后 vendor 状态混乱，怎么安全清场？
别只删 vendor。缓存、临时文件、OPcache 都可能让 Composer 误判或加载旧类。必须连带清理三处：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 删干净
vendor：用命令行强制删，Windows 推荐rd /s /q vendor（比资源管理器可靠），Linux/macOS 用rm -rf vendor - 清 Composer 缓存：
composer clear-cache—— 否则它可能从损坏的 zip 缓存里解包，复现相同错误 - 清 PHP OPcache（尤其 Web 环境）：
opcache_reset()或重启 PHP-FPM/Apache，否则Class not found错误可能持续存在，即使vendor已重装
composer.lock 被改过或校验失败怎么办？
composer install 依赖 composer.lock 的完整性。如果它被 Git 拉取时换行符损坏、手动编辑过、或和 composer.json 不一致，install 会直接失败，报 lock file is not up to date 或哈希校验错误。
- 先验证：
composer validate，看是否提示 lock 文件问题 - 若
composer.lock是干净的（git status显示未修改），但 install 仍失败，加--no-cache参数重试：composer install --no-cache - 若
composer.lock确实损坏或丢失，且你有 Git 历史：git checkout HEAD -- composer.lock，再删vendor重装 - 若 lock 文件彻底没了又没 Git 备份，
composer install会退化为update行为 —— 版本不再可控，这是最后手段
为什么不能用 composer update 回滚中断的安装？
composer update 的目标是“找最新兼容版本”，不是“还原上次状态”。它会重算整个依赖树、忽略 composer.lock 的哈希和提交约束（比如 "dev-main#abc123"），甚至把 require-dev 包也拉进来（除非加 --no-dev）。这和你想恢复“中断前那个确定状态”的目标完全相反。
- 典型后果：
monolog/monolog从2.9.0升到3.0.0，触发 BC break - 更隐蔽的问题：私有包的 dist URL 在 lock 里写的是内网地址，
update可能 fallback 到 public packagist，拉错源 - 唯一例外：你明确想升级某个包，且已删掉它的
vendor/vendor-name/package目录，此时用composer require vendor-name/package:2.9.0是安全的 —— 它只动这个包，不碰其他
真正关键的点不是“怎么删”，而是“删完之后 Composer 怎么判断该做什么”。它只认两个信号：vendor 是否为空 + composer.lock 是否可信。其余所有操作（缓存、OPcache、平台配置）都是为这两个信号服务的。漏掉任意一环，就可能让恢复变成“看似成功，实际埋雷”。
