composer.lock是PHP项目依赖的精确快照，非缓存文件；install必须读它才能严格按锁定的版本、URL、commit hash和SHA256还原vendor目录，否则退化为不可控update，导致环境不一致。
composer.lock 不是缓存或临时文件，它是 PHP 项目依赖的“精确快照”——团队所有成员和 CI 环境必须依赖它，才能确保装出来的 vendor 目录一模一样。
为什么 install 必须读 lock 文件
composer install 的唯一依据就是 composer.lock。它完全忽略 composer.json 中的 ^、~ 或其他版本约束，只安装 lock 文件里写死的版本号、dist URL、commit hash 和 SHA256 校验值。没有这个文件，install 就会退化为 update，重新解析整个依赖图，结果不可控、不可重现。
- 本地能跑，CI 报
Class not found？大概率是 lock 没提交或被 .gitignore 误删 - 同事装出 guzzlehttp/guzzle 7.8.1，你装出 7.9.0，但都没改 composer.json？说明 lock 缺失，install 实际执行了隐式 update
- 跳过 lock 解析阶段，安装速度明显更快，尤其在 CI 中节省大量构建时间
哪些修改必须更新并提交 lock
只有当 composer.json 中影响依赖解析逻辑的部分发生变化时，才需要运行 composer update 并提交新 lock。这不是“每次改 json 都要更新”，而是有明确边界的。
- 增删 require 或 require-dev 中的包（如
composer require phpunit/phpunit） - 修改版本约束（如把
"laravel/framework": "^10.0"改成"^11.0"） - 调整 platform（如统一设
"php": "8.2.0"）、minimum-stability 或 prefer-stable - 仅改 autoload、scripts、name、description 等字段，无需 update，lock 保持原样
Git 冲突时千万别手动合并 lock
composer.lock 是完整依赖树的序列化结果，不是普通 JSON 配置。手动删冲突标记、凑合保留某几行、用格式化工具“美化”，都会破坏哈希校验、包顺序或 JSON 结构，导致后续 install 失败或运行时异常。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法：先确保 composer.json 已合并完成（可读、可审、可测）
- 然后删除 vendor/ 和 composer.lock
- 运行
composer update --no-install，仅生成新 lock - 检查输出是否符合预期，再 git add && commit
CI/CD 流程中 lock 文件的硬性要求
生产部署和 CI 构建必须使用 composer install，且不能跳过 lock。任何绕过它的做法（比如在脚本里加 --ignore-platform-reqs、删 lock 后再 install、或直接用 update）都在主动放弃环境一致性。
- CI 脚本里禁止出现 composer update，除非是独立的安全审计任务
- 建议加
composer install --dry-run做前置校验：失败说明 composer.json 和 lock 不匹配，应阻断构建 - 应用型项目（Laravel/Symfony 网站、API 服务）必须提交 lock；纯库项目（供别人 require 的 package）则不应提交
