最稳的恢复路径是删 vendor 和 composer.lock、切阿里云镜像、再执行 composer install；因 update 会重算依赖树，易触发残留损坏导致冲突或静默失败，而 install 只按 lock 文件精确还原，更可靠。
直接删 vendor 和 composer.lock，切阿里云镜像，再跑 composer install——这是最稳的恢复路径，不是“试试看”，而是当前环境下唯一能绕过残留损坏状态的操作。
为什么不能继续用 composer update
composer update 会重新计算整个依赖树，一旦之前中断过，composer.lock 里可能混着旧镜像地址、半解析的约束或已失效的包哈希。它不关心 vendor 是否残缺，只管“重算”，结果往往是更深层的冲突或静默跳过错误包。而 composer install 只按 lock 文件原样还原，只要 lock 本身没被手动改坏，就能跳过解析阶段，直奔下载安装。
- 执行
composer update --dry-run -v如果输出里出现cannot be installed或反复卡在某个包，说明解析器已陷入死循环，此时 update 已不可信 - 若
composer.lock里还存着packagist.laravel-china.org这类已下线域名，update 会尝试访问并失败，但不会报明确错误，只停在某一步不动 - Composer 2.5+ 版本对 lock 文件校验更严格，哪怕一个字段缩进不对，
update都可能拒绝继续
镜像必须切到阿里云且确认生效
腾讯云镜像偶有同步延迟，华为/PHPChina 等旧镜像已全量下线。如果 composer config -g repo.packagist 输出里还有 https://packagist.phpcomposer.com，立刻执行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 别跳过
config -g检查——项目级composer.json中的repositories字段会覆盖全局设置，得顺手检查是否存在硬编码旧地址 - 切完镜像后运行
composer diagnose，确认输出中Repo packagist is default变成Repo packagist is private且 URL 是阿里云地址 - 如果之前用过
self-update升级失败，先临时切回官方源：composer config -g repo.packagist composer https://packagist.org，升级完再换回来
auth.json 缺失会导致看似正常的 install 失败
私有包（GitLab/GitHub 私仓、Satis、Artifactory）的凭据存在 ~/.composer/auth.json 或项目根目录 auth.json，它不随版本控制提交，迁移或重装后极易丢失。现象是 composer install 跑到某个私有包时突然报 Failed to authenticate，但其他包都正常。
- 运行
ls -la ~/.composer/auth.json确认文件存在；若不存在，检查~/.composer/config.json里是否有http-basic类配置，那也是凭据来源 - 恢复时务必执行
chmod 600 ~/.composer/auth.json，权限大于 600 Composer 会直接忽略该文件 - 项目级
auth.json需要额外启用：composer config --auth http-basic.gitlab.example.com token user，否则不会读取
真正麻烦的不是命令输错，而是 vendor 目录里混入了 src/ 但没有 composer.json 的“半成品包”，或者 lock 文件里记录了已下线镜像的包路径——这些状态不会报错，但会让后续所有操作在暗处失效。所以清理和重装不是兜底方案，是必要前置动作。
