必须人工介入判断：报错含具体行号（如Parse error on line 27）为真损坏，仅“The lock file is not up to date”属过期；composer.json损坏表现为php -l或composer validate直接失败，composer.lock损坏则validate标出无效行号且常见Git冲突或截断；编码问题（如BOM）需file -i检测并sed清除；可信vendor可单删lock后--no-cache重建，否则须清空vendor与lock；--no-cache防缓存坏包，国内镜像URL须以/结尾；重建后须--dry-run验证及比对dist.sha256一致性。
composer.json 或 composer.lock 文件损坏，不能靠 composer install 自动修复——它只读取文件，不校验语法、不提示截断、更不会重写。必须人工介入判断类型，再选对应动作。
怎么判断是 composer.json 还是 composer.lock 损坏
错误信息里带具体行号（比如 Parse error on line 27）就是真损坏；只报 The lock file is not up to date 是过期，不是损坏。
-
composer.json损坏：运行composer validate直接失败，或php -l composer.json报语法错 -
composer.lock损坏：composer validate输出./composer.lock is invalid并标出行号，常见于 Git 冲突残留（<<<< HEAD）、断电导致 JSON 截断、编辑器意外写入空字节 - 两者都看似“乱码”但没报错？大概率是编码问题（如 UTF-8 BOM），用
file -i composer.json查编码，用sed -i '1s/^\xEF\xBB\xBF//' composer.json去 BOM
损坏的 composer.lock 能不能只删它不删 vendor/
能，但前提是 vendor/ 当前状态可信：目录非空、vendor/autoload.php 可执行、vendor/composer/installed.json 是完整 JSON。
- 满足上述条件：备份原
composer.lock，删掉它，再跑composer install --no-cache—— 它会基于现有vendor/重建锁文件 - 不满足（比如
vendor/是空的、或installed.json是零字节）：必须一起删vendor/和composer.lock，否则install会卡在解压环节 - 千万别用
composer update --lock替代：它会查远程最新版，可能升级一堆包，彻底偏离原依赖树
为什么加 --no-cache 是关键一步
断电或磁盘异常后，~/.composer/cache/files/ 里很可能存着截断的 ZIP，而 composer install 默认优先复用缓存——等于把坏包又装一遍。
-
--no-cache强制跳过本地所有缓存 ZIP 和元数据，从镜像源重新拉原始包 - 国内用户务必确认镜像 URL 以
/结尾：composer config -g repo.packagist输出必须是{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}，少斜杠就静默 fallback 到官方源 - 如果仍失败，先
composer clear-cache，再加--no-cache执行，双保险
最容易被忽略的验证点
重建完 composer.lock 后，别急着提交或上线。
- 跑
composer install --dry-run：如果还有包显示Installing或Updating，说明锁文件和当前vendor/不一致 - 比对
vendor/composer/installed.json和composer.lock中同一包的dist.sha256值是否完全一致——不一致会导致后续install提示Corrupted - CI/CD 中若复用
~/.composer/cache，不同 PHP 版本下生成的 autoload 映射可能冲突，这是最隐蔽的Class not found根源
