composer.lock 是依赖的精确快照，必须提交至 Git；它记录每个包的确切版本、哈希值与完整依赖树，确保 composer install 在所有环境安装完全一致的依赖，避免因版本波动引发兼容性问题。
composer.lock 是依赖的“快照”，不是可选附件
它记录的是当前项目 vendor/ 目录里**每一个包的确切版本、源码哈希、dist 地址、完整依赖树**——不是你“想装什么”，而是你“实际装了什么”。没有它，composer install 就会退化成按 composer.json 重新解析版本，同一行 "monolog/monolog": "^2.5" 在 CI、测试机、生产服务器上可能分别装出 2.5.0、2.8.2、2.9.3，而其中某个 patch 版本可能悄悄改了返回类型或废弃了一个方法。
- 必须提交到 Git，和
index.php或.env.example一样关键 - CI/CD 部署时只允许用
composer install（读 lock），严禁用composer update - 本地开发时若删了它，
composer install会重建，但结果不可控——这不是“重装”，是“重算”
composer.json 和 composer.lock 的分工非常明确
composer.json 是人写的说明书：require 告诉 Composer “我需要 monolog，至少 2.0”，autoload 告诉它“我的类怎么加载”。它管意图，不保结果；composer.lock 是机器生成的收据：它写明“这次装的是 monolog v2.9.1，dist 包 SHA256 是 xxx，它的依赖 psr/log 是 v1.2.3，也一起锁死了”。只要 lock 文件存在，Composer 就完全忽略 json 里的 ^ 或 ~ 约束，只认 lock 里写的 exact version。
- 改需求？编辑
composer.json，然后运行composer update monolog/monolog - 同步环境？拉代码后直接
composer install，别手痒去update - 合并分支遇到 lock 冲突？优先保留对方的 lock，再跑一次
composer update --dry-run验证是否引入意外变更
常见错误：手动编辑 lock 文件 or 忽略它
有人看到某依赖版本太低，就直接打开 composer.lock 把 "version": "2.1.0" 改成 "2.9.1"——这会导致哈希校验失败，下次 composer install 会报错退出；还有人觉得“反正 json 里写了范围，lock 不重要”，于是 .gitignore 里加了 /composer.lock，结果上线后发现日志突然不写了，查半天才发现 monolog 被自动升到了 v3，而项目代码还调用着已被移除的 Logger::getLevel()。
