composer install 无法修复已破坏的依赖，因其仅按 composer.lock 还原状态，不解决冲突；破坏常因 lock 与 json 不一致、lock 缺失或本地环境不匹配所致，需先诊断类型再针对性处理。
composer install 本身不更新依赖，它只还原 composer.lock 中记录的状态——所以当依赖“已被破坏”，直接运行 composer install 不仅不能修复，反而会稳定复现问题。
为什么 composer install 无法修复已破坏的依赖
破坏通常源于以下情况之一：composer.lock 与 composer.json 不一致、lock 文件被删或过期、本地 PHP 版本/扩展与 lock 记录不匹配。而 composer install 的设计原则就是“不求解、不协商、不改写”，它只校验 lock 文件完整性并按图索骥安装。一旦 lock 里存了冲突版本或不兼容扩展（如要求 ext-gmp 但未启用），install 就会失败或装出不可用环境。
先确认破坏类型，再决定是否真要 run install
常见破坏现象及对应动作：
- 报错
Your lock file does not contain a compatible set of packages：说明composer.json已改但composer.lock没同步 —— 此时不该install，而应composer update --lock（仅重写 lock，不重装） - 报错
Conclusion: don't install xxx v2.1.0：lock 文件本身没问题，但本地平台（PHP 版本、扩展）与 lock 中记录的约束冲突 —— 先检查php -v和php -m，再确认composer.json的config.platform.php是否匹配 - 装完能跑但功能异常（如日志不写、HTTP 超时变短）：大概率是 lock 文件长期未提交，团队成员 install 的其实是旧版 —— 运行
git diff composer.lock看是否遗漏提交，而不是重跑 install
真正安全的“恢复”路径：绕过 install，直击源头
如果你确定当前 lock 文件已失效（比如被误删、CI 构建失败后手动改过 json），安全做法不是靠 install 猜测还原，而是重建可信状态：
- 从 Git 历史找回上一个可用的
composer.lock：git checkout HEAD~1 -- composer.lock，再composer install - 若无历史 lock，且你清楚哪些包必须锁定：先
composer install --no-dev --dry-run预览将装什么，确认无高危升级（如主版本跳变），再执行真实 install - 生产环境严禁用
composer update补救 —— 但开发机上可临时composer update --with-dependencies vendor/package定点修复后，立刻git add composer.lock提交，供其他人 install
最易被忽略的一点：很多“破坏”其实发生在 vendor/ 目录权限、OPcache 未清理、或 autoloader 缓存残留——此时重装依赖毫无意义，rm -rf vendor/ && composer install 才是真正起点。
