composer.lock 是生产环境依赖一致性的强制契约，非缓存；冲突时应使其与 composer.json 对齐或由 composer 重算，而非直接删除。
直接结论：composer.lock 不是“缓存”，它是生产环境依赖一致性的强制契约；冲突时别删它，要让它和 composer.json 对齐，或让 Composer 重算它。
composer install 报 “has been locked to a version that does not exist” 怎么办
这是 composer.lock 记了一个根本不存在的版本（比如 monolog/monolog:2.10.0-rc1），常见于预发布标签被作者删除、私有包镜像未同步、或手动编辑 lock 文件出错。
- 先确认报错中的包名和版本：
Package monolog/monolog has been locked to version 2.10.0-rc1 - 如果是公共包，打开
https://packagist.org/packages/monolog/monolog查该版本是否存在 - 如果是私有包，检查
composer config --list中的仓库配置和 token 是否有效 - 确认版本确实不存在？最稳妥做法是删掉
composer.lock和vendor/，再跑composer install—— 它会重新解析出当前可用的最新兼容版本 - 想保留部分已安装包？可手动编辑
composer.lock，删掉对应包的整个区块（含name、version、dist、source），保存后重试composer install
composer install 报 “Your lock file does not contain a compatible set of packages” 怎么办
这说明 composer.json 已改（比如加了新包、调了 PHP 版本约束），但 composer.lock 还是旧的，Composer 拒绝“睁眼装”——它不是版本太高，是 json 和 lock 不匹配。
- 最干净做法：删掉
composer.lock，再执行composer install，全量重解依赖树 - 想保留当前已安装的包版本？用
composer update --lock，它只更新 lock 文件结构，不改任何包版本 - CI/CD 中必须确保
composer.lock已提交且未被.gitignore，否则每次构建都可能装出不同结果 - 别用
--ignore-platform-reqs硬扛，那只是掩盖问题，不是解决冲突
为什么锁定了版本，composer install 却没更新 vendor 里的代码
现象是改了 composer.json 里某个包的版本（如 "topthink/framework": "6.3.5"），但 composer install 后 vendor/topthink/framework 仍是旧版。根本原因通常是 composer.lock 仍锁着旧版，或 Composer 缓存了旧解析结果。
- 先看
composer.lock里对应包的version字段是否真改了；没改就说明composer install根本没触发重算 - 改了
composer.json后，必须运行composer update vendor/package或composer update --lock才会同步到 lock 文件 - 别信
composer require vendor/package:1.2.3 --no-update—— 它只改 json，不碰 lock 和 vendor，冲突照旧 - 若怀疑缓存干扰，可加
-v参数运行composer install -v，看输出里是否跳过了该包的安装步骤
composer update 后 vendor 代码变了，但 composer.lock 没提交，会发生什么
这是团队协作中最容易被忽略的断裂点：lock 文件没提交，等于把“依赖契约”留在了你本地。
- 别人拉代码后执行
composer install，会按他们本地的 lock 文件装 —— 可能是上周的版本，也可能是空 lock，结果完全不可控 - CI 构建时若没找到 lock 文件，Composer 会退回到按
composer.json重算，极大概率装出和你本地不一致的依赖树 - 从 Composer 2.5 开始，如果
composer.lock缺少composer.json要求的包，install会直接报错，进一步暴露这个问题 - 真正生效的锁定，永远依赖
git add composer.lock && git commit—— 它不是可选项，是强制动作
