composer.lock存packages、packages-dev和content-hash三大关键字段：packages和packages-dev记录每个包的精确version、source.reference（Git commit hash）及dist.shasum（校验和），content-hash则校验composer.json内容是否变更。
composer.lock 里到底存了哪些关键字段
它不是版本号列表，而是一份完整依赖快照，包含每个包的精确安装元数据。只要 composer.lock 存在且未被跳过，composer install 就只会按它还原，完全无视 composer.json 中的 ^ 或 ~。
-
version字段是真正生效的版本字符串，比如"2.9.1"—— 这才是最终装进vendor/的版本，不是composer.json里写的那个“意向” -
source下的reference是 Git commit hash，确保源码可追溯；dist下的shasum是 ZIP 包校验和，防止下载篡改 -
packages和packages-dev分开记录，但都包含嵌套依赖路径（require字段），说明这个包是怎么被拉进来的 -
content-hash是整个composer.json的哈希值，不是版本快照本身——它只用于检测composer.json是否被修改，不参与安装逻辑
为什么删掉 composer.lock 后 composer install 会升级
因为 composer install 没有 lock 文件可依，就自动 fallback 到 composer update 行为：重新解析所有约束、查最新兼容版本、生成新依赖树。这不是“重装”，是彻底放弃控制权。
- 哪怕
composer.json写着"monolog/monolog": "2.9.1"，删掉 lock 后执行install，仍可能装上2.9.2（如果镜像缓存了新版本且满足约束） - 更危险的是间接依赖漂移：比如
guzzlehttp/guzzle没写死，但它的子依赖psr/http-message可能从1.0.1升到2.0.0，引发接口不兼容 - Docker 构建或 CI 环境若没提交
composer.lock，每次构建都可能拿到不同vendor/，连git diff都看不出问题
composer.lock 被改了但没察觉，怎么快速验证
别只看 Git diff，得确认实际行为是否还受控。最直接的方式是用命令交叉验证当前状态是否与预期一致。
- 运行
composer show monolog/monolog，输出的versions必须和你期望的精确版本完全一致（如2.9.1） - 再跑
composer update --dry-run monolog/monolog，如果提示Nothing to install or update，说明 lock 和 json 已对齐，该包确实被锁死 - 打开
composer.lock搜索包名，检查version字段是否为纯数字、三位完整（"2.9.1"✅，"2.9"❌），且source.reference是确定 commit - CI 脚本里加一行
composer install --locked，它会在安装前校验 lock 中每个版本是否仍满足composer.json的约束，不满足直接报错退出
团队协作中最容易被忽略的细节
不是命令记不住，而是对 composer.lock 的角色认知偏差——它既不是缓存，也不是临时文件，而是部署契约的物理载体。
- 有人在改完
composer.json后只跑composer install，忘了update才能更新 lock；结果 push 的是旧 lock，别人install出来还是老版本 - 有人把
composer.lock加进了.gitignore，尤其在 Laravel Starter 项目里误以为它是“开发专属”，导致所有环境都不可重现 - CI 脚本里混用
composer update和install，甚至加了--no-lock参数，等于主动关闭锁定机制 -
composer.lock提交后，Git diff 显示 platform 字段格式变化（比如 PHP 版本字符串加了引号）、字段顺序调整，这不代表版本漂移，但可能掩盖真正的变更
