直接结论：该问题源于 composer.lock 与 composer.json 声明不一致，Composer 拒绝按过期 lock 文件安装，须先同步 lock 文件再执行 install。
一句话说透：这个报错的本质，并非某个包真的“没装”，而是 composer.lock 和 composer.json 这两个文件对不上号了。Composer 拒绝按照一份过期的“购物清单”来执行安装——所以，你得先同步锁文件的状态，才能顺利 install。
为什么 composer install 会报 “package not found” 或 “does not exist in lock file”？
这个场景太常见了：从同事那里拷贝了一份 composer.json，兴冲冲地运行 composer install，结果终端飘红；或者，想用 composer remove xxx 清理一个包，却被告知它“不在 lock 文件里”。
其实，问题的根子往往不在 vendor 目录缺东西，而是出在 composer.lock 这个文件上。具体来说，无非三种情况：
composer.lock文件压根不存在；- 它被
.gitignore之类的规则忽略了，导致项目里没有； - 或者，它的内容和你当前的
composer.json对不上。
这里有个关键逻辑需要理解：composer install 这个命令，默认是只认 composer.lock 的。它不会去解析 composer.json 里写了什么，而是把 lock 文件当作一份“权威安装清单”，照单全收。一旦这份清单缺失、或者内容“失效”，Composer 就会直接拒绝继续，以此保证环境的一致性。所以，当你从 Git 克隆项目后，如果发现原仓库没提交 lock 文件，或者在 CI 环境里它被误删了，这类报错就会立刻跳出来。
同步 lock 文件的三种实操路径
知道了原因，解决起来就有方向了。根据你手头的情况和目标，选择下面最对路的一条命令来执行，千万别混着用：
- 场景一：刚克隆了项目，并且原项目是提交了
composer.lock的。
这是最理想的情况。你只需要确保这个 lock 文件被正确复制到了你的本地项目根目录，然后直接运行composer install即可。这是最安全、最还原原始依赖状态的做法。 - 场景二：刚克隆了项目，但原项目压根没提交
composer.lock。
这时候，你需要先在原项目的开发环境中，运行composer update --lock来生成一份 lock 文件。然后，把这份新生成的 lock 文件复制到你的本地，再执行composer install。 - 场景三：你在本地修改了
composer.json（比如增删了包，或者调整了版本约束），但还没同步到 lock 文件。
这是开发中最常遇到的情况。你必须运行composer update（在开发环境中，这会更新包到符合约束的最新版本）或者composer update --lock（如果只想刷新 lock 文件结构，而不升级任何包版本的话）。
composer update --lock 不是万能同步键，用错反而埋坑
这个命令经常被误解为“轻量级的 update”，但它的行为其实很特别，用错了会留下隐患。
核心在于：composer update --lock 根本不会校验 composer.json 里声明的依赖版本约束是否发生了变化。举个例子，如果你把 "monolog/monolog": "^2.9" 改成了 "^2.10"，然后运行这个命令，lock 文件里记录的 monolog 版本依然会是旧的 2.9.x——它会静默地忽略你的版本约束变更。
那么，它真正该用在什么场景呢？范围其实很窄：比如切换 PHP 版本后，需要更新 lock 文件里的 platform 字段；或者仅仅想修复 lock 文件的缩进格式、对齐仓库（repositories）配置等元信息。在这些不涉及依赖解析的“表面刷新”时，它才派上用场。
如果你不确定该用哪个命令，这里有个安全小技巧：先运行 composer update --dry-run。这个命令会完整地解析所有依赖约束，并模拟更新过程，清晰地告诉你哪些包会被改变。如果它的输出是 Nothing to install or update，那恭喜你，说明当前的 lock 文件已经是最佳状态，可以直接进行 install 了。
团队协作中 lock 文件必须进 Git，且每次改 json 就要提新 lock
这是避免“在我机器上好好的，怎么到你那儿就装不上”这类扯皮问题的黄金法则，没有例外。
- 铁律一：提交。 必须确保
composer.lock文件不在.gitignore的排除列表里，并且要和composer.json一起提交到版本库。 - 铁律二：同步。 任何对
composer.json的修改（增、删、改版本），都必须立刻运行对应的命令（composer update [包名]或特定场景下的composer update --lock），生成新的 lock 文件，并立即提交。 - 铁律三：验证。 在 CI/CD 流水线里，加入一步
composer install --dry-run作为前置检查。如果这步失败了，就直接中断构建流程——它能最早地暴露 lock 文件和 json 文件不一致的问题，把错误扼杀在提交阶段。
最后，分享一个最容易被忽略的认知误区：很多人觉得“只要 install 能顺利跑通、把包装上就行了”。但事实上，lock 文件一旦没有及时跟上 json 的变更，就等于埋下了一颗定时冲击波。下一位拉取代码的队友，就会在第一步安装依赖时卡住。记住，composer.lock 从来都不是可有可无的辅助文件，它是项目依赖关系的权威事实快照，是保证团队环境一致的基石。
