composer.lock损坏后不可删锁重跑install，必须用composer update --lock仅重写lock文件；若vendor也损坏则先删vendor再install；两者均不可信时才执行rm composer.lock && rm -rf vendor && composer update。
composer.lock 损坏不能删了重跑 composer install，它根本不会工作——没 lock 就没还原依据。 正确路径取决于损坏范围：仅 lock 文件异常？vendor 还在？还是连本地包路径都变了？下面分情况说清怎么做、为什么、容易在哪卡住。
composer.lock 报 JSON decode error 或出现
这类错误基本等于 lock 文件已失效。Git 合并冲突残留、编辑器换行符错乱、手动改字段顺序都会破坏哈希校验，因为 composer.lock 不是普通 JSON，字段顺序和空格参与签名。
- 看到
等标记？别手动删冲突段，用 <code>git checkout --ours composer.lock或--theirs恢复任一干净版本 - 恢复后立刻执行
rm -rf vendor/，再跑composer install——如果当前composer.json和恢复的 lock 不兼容，会立刻报错，逼你确认状态 - 若想让 lock 对齐当前 vendor（比如你本地改过包但忘了 update），就跑
composer update --lock，它只序列化 vendor 中已装的包，不升级、不重解依赖
vendor 目录缺失或 autoload.php 找不到类怎么办
这说明不只是 lock 问题，依赖文件本身已不可信。常见于误删 vendor、rsync 复制软链接失败、或缓存 ZIP 下载损坏。
- 先删掉整个
vendor/：rm -rf vendor - 确保
composer.lock存在且能被正确解析（composer validate可快速验证） - 直接运行
composer install，它会按 lock 精确还原，比update更稳定 - 如果仍报
Class not found，检查vendor/autoload.php是否生成成功；没生成说明composer install实际中途失败，要翻最上面的错误行
本地 path 仓库迁移后软链接失效怎么恢复
composer link 是纯运行时快捷方式，不写入 composer.lock，复制到新环境必然断链。真正可迁移的是 path 类型仓库机制。
- 确认主项目
composer.json的repositories里有类似{"type":"path","url":"../my-local-package"}的配置 - 确保本地包根目录下有合法
composer.json，含name、version、autoload - 新服务器上先
ls -l ../my-local-package确认路径可达，权限可读 - 运行
composer install（别加--no-dev，path 包默认属 dev）——只要 lock 里记录了"type": "path"，就会自动重建软链接
镜像源切换后依赖图不全或子依赖丢失
私有仓库（如 Satis）若元数据导出不全，composer install 会只装顶层包，跳过 require 字段声明的子依赖，导致 Class "Illuminate\Foundation\Application" not found 这类致命错误。
- 检查
packages.json中对应包的条目是否包含完整require字段，缺失即为元数据不全 - Satis 配置中必须启用
providers并补全映射，不能只靠"providers": ["*"]而忽略字段继承 - 临时验证：切回官方源
composer config --unset repos.packagist+composer clear-cache+composer install，若正常则锁定是私有源问题 - 别用
composer update强刷——它可能绕过损坏的元数据，给出看似成功实则漏依赖的结果
最易被忽略的一点：所有修复动作都依赖 composer.lock 和 composer.json 的一致性。哪怕只改了一行版本号，也得重新跑 composer update --lock 或 composer install 来对齐状态。靠“感觉差不多”跳过验证，往往在 CI 或上线时才暴露。
