Composer lock文件有什么用_Composer.lock与json区别解析【科普】

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()。

• lock 文件结构复杂，含嵌套依赖、多层哈希、dist/source 切换逻辑，手工维护=自找麻烦
• 要升级？用 composer update vendor/package，它会自动更新 lock 并校验一致性
• 要回退？用 git checkout HEAD~1 -- composer.lock && composer install，而不是改 json 后硬装

vendor/composer/installed.json 是另一个容易被误解的文件

它不是 lock，也不是 json，而是 Composer 在每次安装成功后，对 vendor/ 目录做的“现场拍照”：记录每个已安装包的路径、autoload 配置、是否为 dev 依赖等。它不参与版本控制，也不决定安装行为，只是 vendor/autoload.php 生成时的数据源。你不需要管它，也不该提交它到 Git。

• composer show --installed 显示的内容，就来自这个文件，不是 lock
• 部署工具（如 Capistrano 插件）有时靠它确认 vendor/ 是否完整，而非只看目录是否存在
• 删掉它？下次 composer install 会自动重建；改它？没用，会被覆盖

真正难的不是理解 lock 文件的作用，而是团队里每个人都坚持「改 json 就 update，拉代码就 install，lock 必须进 Git」——一旦有一个人跳过流程，一致性就崩了。