直接结论：该问题源于 composer.lock 与 composer.json 声明不一致，Composer 拒绝按过期 lock 文件安装，须先同步 lock 文件再执行 install。
直接结论：这个提示本质是 composer.lock 和 composer.json 的声明不一致，不是包“没装”，而是 Composer 拒绝按过期的 lock 文件安装——必须先同步锁文件状态，再 install。
为什么 composer install 报 “package not found” 或 “does not exist in lock file”
常见错误现象：复制了别人的 composer.json，运行 composer install 却失败；或执行 composer remove xxx 提示包不在 lock 文件里。
- 根本原因不是 vendor 缺失，而是
composer.lock不存在、被忽略（如 .gitignore）、或内容与当前composer.json不匹配 -
composer install默认只信任composer.lock——它不解析composer.json，只照单安装。没有 lock 文件或 lock 文件“失效”，它就拒绝继续 - Git 克隆项目后没提交
composer.lock，或 CI 环境误删了它，都会触发这类报错
同步 lock 文件的三种实操路径
根据你当前想达成的目标选对应命令，别混用：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 刚克隆项目，且原项目有
composer.lock→ 直接复制过去，再运行composer install（最安全） - 刚克隆项目，但原项目没提交
composer.lock→ 在原项目根目录运行composer update --lock生成它，再复制 +composer install - 本地改过
composer.json（增删包、调版本），但没同步 lock → 必须运行composer update（开发环境）或composer update --lock（仅刷新结构，不升级包）
composer update --lock 不是万能同步键，用错反而埋坑
这个命令常被误当成“轻量版 update”，但它根本不校验 composer.json 里的依赖变更：
- 如果你把
"monolog/monolog": "^2.9"改成"^2.10"，再跑composer update --lock，lock 文件里仍会保留旧版本 —— 它静默忽略约束变化 - 真正该用它的场景很窄：PHP 版本切换后补全
platform字段、修复 lock 文件缩进、对齐 repositories 配置等元信息刷新 - 不确定是否该用？先跑
composer update --dry-run：它会完整解析约束并告诉你哪些包会变，输出Nothing to install or update才说明 lock 已就绪
团队协作中 lock 文件必须进 Git，且每次改 json 就要提新 lock
这是唯一能避免“别人能装、你装不了”的硬规则：
-
composer.lock必须在.gitignore之外，和composer.json一起提交 - 修改
composer.json后，立刻运行对应命令（composer update xxx或composer update --lock），生成新 lock 并提交 - CI 流水线里加一步
composer install --dry-run，失败即中断构建——它能提前暴露 lock/json 不一致问题
最易被忽略的点：很多人以为“install 能装出来就行”，但 lock 文件一旦没跟上 json 变更，下次有人拉代码就会卡在第一步。它不是辅助文件，是依赖事实的权威快照。
