应执行composer update --lock：该命令仅根据当前composer.json重新生成composer.lock，不修改vendor目录或升级任何包，确保环境一致性。
composer install 报 “The lock file is not up to date” 怎么办
这不是错误，是 Composer 在提醒你：当前 composer.json 已被修改（比如增删包、改版本、调 platform），但 composer.lock 还没同步更新。它拒绝按旧锁文件安装，防止环境不一致。
- 先确认是否真改过
composer.json：用git status或对比最近一次提交 - 如果确实改了，就该跑
composer update --lock—— 它只重写composer.lock，不碰vendor/，也不升级任何包 - 如果没改过
composer.json却报这个，检查是否误触了composer require或 IDE 自动同步功能（如 PHPStorm 的「Synchronize composer.json on changes」） - 别用
composer update代替：它会重新求解整个依赖树，可能升一堆包，偏离原环境
为什么不能直接删 lock 再 install
删掉 composer.lock 后执行 composer install 会立刻失败，报错 Lock file does not exist. Run composer update to create it. —— 因为 install 的设计前提就是锁文件存在，它不负责生成锁。
- 想重建锁，必须用
composer update（或composer update --lock，取决于你是否改过composer.json） - 误删后又硬跑
install，新版 Composer（v2.5+）会直接报Command "install" is not defined，旧版则可能静默失败，导致vendor/不完整 - CI 脚本里漏传
composer.lock，等同于放弃环境一致性：不同构建节点可能装出guzzlehttp/guzzle的不同 patch 版本
composer update --lock 和 composer update 有什么区别
composer update --lock 是安全更新锁文件的唯一推荐方式；composer update 则是重算全部依赖，风险高得多。
-
composer update --lock：只根据当前composer.json重新生成composer.lock，不安装、不卸载、不升级任何包，vendor/完全不动 -
composer update：读取composer.json约束，调用 SAT 求解器，可能升级主版本、次版本、补丁版本，甚至引入新包或移除旧包 - 加
--dry-run可预览update会做什么，但--lock没有 dry-run 模式——它本来就不改变运行时状态 - Git 提交前，务必确认
composer.lock的content-hash是否变化：变了说明依赖图真有调整，需要走完整测试流程
CI/CD 中遇到 lock 过时报错，该怎么写脚本
CI 环境里最怕的是“本地能跑，CI 报错”，核心是确保 composer.json 和 composer.lock 始终配套，且锁文件被正确检出。
- 第一步永远是
git checkout -- composer.lock（或从 artifact 恢复），避免合并冲突残留导致校验失败 - 第二步运行
composer install --no-interaction --no-progress，不加--no-dev除非明确要跳过 dev 包 - 如果 CI 报
Your lock file does not contain a compatible set of packages，说明composer.json和所用composer.lock不匹配，应中止构建，而不是强行update - 镜像源不同步（如阿里云延迟 10–30 分钟）可能导致
composer update找不到新分支，此时换源比清缓存更有效：composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/
真正容易被忽略的是：过时的 lock 文件本身不是问题，问题是它和 composer.json 的不一致被放任不管。一旦 merge 到 main，后续所有基于该 lock 的部署都会继承这个偏差。
