“Your lock file is not up to date”不是错误，而是提示composer.json与composer.lock顶层依赖声明不一致；需据操作目的选命令：仅改非依赖字段时用composer update --lock-only重写lock哈希与元数据而不动vendor。
“Your lock file is not up to date” 不是错误，而是 Composer 在明确告诉你：当前 composer.json 和 composer.lock 的顶层依赖声明不一致。该用哪个命令，取决于你到底想干什么——不是所有场景都该跑 composer update。
什么时候必须用 composer update --lock-only
你只改了 composer.json 里的非依赖字段（比如加了 "description"、调整了 "config": {"sort-packages": true}、删了注释、换了缩进），但 composer install 却报同步警告。这是因为 content-hash 校验失败，而你根本没动任何包版本。
-
composer update --lock-only是唯一安全方式：它验证已安装包是否仍满足composer.json所有约束，仅重写composer.lock中的哈希、排序、格式和元数据，不动vendor/一丁点 - 别用
composer update替代——它会重算整个依赖图，可能升掉你没碰过的包 - 这个命令要求 Composer 2.2+；旧版本可用
composer update --lock，但行为略有差异（见下一条）
composer update --lock 到底在干啥
它完全忽略 composer.json 的任何改动，只对当前 vendor/ 目录做快照：重新计算每个包的 dist.sha256、源地址、依赖树结构，并标准化写回 composer.lock。它不联网、不查 Packagist、不校验约束是否满足。
- 典型用途：修复 Git 自动换行导致的 JSON 格式损坏、统一团队 lock 文件缩进和字段顺序
- 如果你刚手动删了
vendor/但保留了旧 lock，这个命令会直接失败——它依赖vendor/完整且可解析 - 它不会响应你在
composer.json里新加的包，也不会修正版本不一致警告，所以不能替代--lock-only
为什么 composer update --dry-run 救不了哈希不匹配
composer update --dry-run 是模拟完整更新流程：它会走依赖求解、下载元数据、比对版本，只是不真正写文件。但它不会刷新 composer.lock 里的 dist 哈希，也不会校验现有 vendor/ 是否匹配 lock。
-
--dry-run输出Nothing to install, update or remove≠ lock 哈希正确；它只说明版本无变化，不校验哈希 - 如果 lock 里某包哈希已失效，
--dry-run可能静默跳过警告，而真实install时才爆错 - 性能开销远高于
--lock，尤其在大型项目中明显卡顿
CI 构建失败时最常踩的坑
CI 报 “Lock file is not up to date” 99% 是 PR 提交时只改了 composer.json 却漏跑 composer update，或 composer.lock 被 .gitignore 错误忽略了。
- 构建阶段的目标是复现环境，不是探索依赖——永远用
composer install，别手抖加update - 若 lock 缺失，先确认
vendor/是否已由上一步安装好，再跑composer update --lock补全格式；否则直接 fail - 长期方案：在
.gitattributes里加composer.lock merge=ours，避免 Git 冲突时手修 JSON
最容易被忽略的是 Composer 版本差异：2.x 生成的 lock 包含 content-hash 和细粒度平台信息，1.10 读取会直接拒绝加载。不是 lock 坏了，是版本越界。团队应统一用 2.x，CI 脚本里别写死 self-update。
