直接结论：遇到“Your lock file is not up to date with composer.json”必须根据目标选择命令——想复现环境就运行composer install，想更新依赖就运行composer update；不可跳过、手动改或删lock重生成。
直接结论：不要跳过、不要手动改 lock、不要删了重生成——先看报错类型和你当前想干什么，再选 composer install 还是 composer update。
看到 “Your lock file is not up to date with composer.json” 怎么办
这是 Composer 的明确拒绝，不是警告。它说明 composer.json 里声明的依赖（比如新加了 "guzzlehttp/guzzle": "^7.8"）在 composer.lock 里找不到对应快照，composer install 就会中止执行。
- 如果你刚拉了别人代码，且确认
composer.lock是最新提交的 → 运行composer install（它只读 lock，不关心 json 变没变） - 如果你自己改了
composer.json（增删包、调版本），并希望生效 → 必须运行composer update或composer update vendor/package - 如果 CI 报这个错，99% 是 PR 提交时只改了
composer.json却漏跑composer update，或composer.lock被.gitignore错误忽略了
composer update --lock 是什么，什么时候用
这个命令只重写 composer.lock 文件内容，不下载/更新任何包，也不修改 vendor/。它适合修复“json 和 lock 结构不匹配但你不想动已装依赖”的场景。
- 常见于：你只调整了
composer.json的格式（比如加了个空行、改了注释）、或加了"config": {"sort-packages": true}，但没改依赖本身 - 不适合：你新增了包、升级了主版本、改了 PHP 平台要求（如
"php": "^8.2"）——这些必须走完整composer update - 执行后务必
git diff composer.lock确认变更是否合理；乱提交一个格式错乱的 lock 会导致所有人install失败
Git 冲突了，composer.lock 怎么安全合并
别打开编辑器手修。lock 文件是结构化 JSON，字段顺序、缩进、逗号、换行都参与校验，任意偏差都会让 composer install 报 file could not be parsed。
- 优先从主干恢复：
git restore --source=origin/main -- composer.lock，再composer install校验是否与当前composer.json兼容 - 长期方案：在项目根目录加
.gitattributes，写入composer.lock merge=ours，让 Git 自动以主干版本为准 - 团队协作前统一开启
"config": {"sort-packages": true}，能大幅减少因包顺序不同导致的“假冲突”
CI/CD 里遇到同步失败，千万别手抖 update
CI 流水线的目标是复现环境，不是探索依赖。在构建阶段跑 composer update 等于放弃可重现性——同一份代码，今天装 v3.1.0，明天可能装 v3.2.0，只要上游发版就崩。
- 正确做法：CI 只跑
composer install --no-interaction --prefer-dist，并确保检出的代码里composer.lock存在且合法 - 前置检查：在 PR 流程加
composer install --dry-run，失败即阻断合并 - 最常被忽略的一点：PHP 小版本差异（如 8.1.22 vs 8.1.25）或扩展缺失（
ext-zip）也会触发 lock 不同步报错，需用composer show --platform对齐
真正麻烦的从来不是命令怎么敲，而是搞不清自己到底要“复现环境”还是“推进依赖”。选错一步，后续所有 install 都会卡住，而且错误信息还藏得深。
