应保留 composer.lock 以定位问题根源；删它会导致 install 失败或 update 带偏依赖；“Package not found”常见于拼写错误、包已下线但 lock 未更新、私有源配置缺失、缓存污染；仅当升级 PHP 大版本冲突或 lock 文件损坏时才删除。
不需要删 composer.lock，反而要先保留它——它能帮你定位问题根源。删了它，composer install 会直接失败，而 composer update 又可能把其他依赖也带偏。
报“Package not found”时，先确认是不是真不存在
错误信息如 Could not find package xxx/yyy 或 Package xxx/yyy not found，不等于包真的没了，常见原因有：
-
composer.json里包名拼错（比如多空格、大小写不符、用了已弃用的别名） - 包已从 Packagist 移除，但
composer.lock还记着旧快照，composer install尝试按 lock 下载时才暴露问题 - 项目配置了私有仓库，但
repositories字段缺失或 URL 错误，导致 Composer 去官方源找，自然找不到 - 本地缓存污染，
composer show xxx/yyy --all返回空，但清缓存后就能看到版本
composer.lock 存在时，用 install 还是 update？
如果 composer.lock 里确实记录了那个包（可用 grep -A5 'xxx/yyy' composer.lock 确认），但 composer install 报找不到，说明分发源不可达或校验失败，此时：
- 不要删
composer.lock，先运行composer clear-cache - 检查镜像是否生效：
composer config -g repo.packagist输出应为完整 JSON，且url末尾有斜杠 - 若包确已下线，
composer update xxx/yyy会报错并中止，不会破坏其他依赖；而删 lock 后跑composer update会重算整棵树，风险不可控
什么情况下才该删 composer.lock？
只有两种明确场景值得删 composer.lock：
- 你确定要彻底放弃当前依赖快照，比如升级 PHP 大版本后，
composer.lock里锁的"platform": {"php": "^7.4"}和本地环境冲突，且你愿意接受所有包重新求解 -
composer.lock文件本身损坏（JSON 解析失败、Git 合并残留 git checkout 恢复干净版本
其余情况，包括包找不到、install 报错、vendor 残留，都不需要也不应该删它——它不是障碍，是线索。
容易被忽略的关键点
composer.lock 里的 content-hash 字段由 composer.json 全文（含空格、换行、字段顺序）生成。改了一行 composer.json 却没跑 composer update，composer install 就会警告“content-hash mismatch”，但默认仍继续执行。这个警告常被跳过，结果是 vendor 装了，autoload 却没更新，类找不到。
