composer.lock 是 Composer 实际生效的版本锁，记录精确版本、hash 和依赖快照；install 优先读 lock，仅 update 或无 lock 时才按 composer.json 解析；必须提交 Git 以保证环境一致。
Composer 不会自动锁定版本，composer.lock 文件才是实际生效的版本锁；没它，每次 composer install 都可能拉到不同版本。
为什么 composer.lock 比 composer.json 更关键
很多人误以为改了 composer.json 里的 "monolog/monolog": "^2.0" 就锁死了版本——其实这只是“允许范围”，真正决定装哪个版本的是 composer.lock。它记录了每个包的精确版本、commit hash、依赖树快照和下载地址。
- 运行
composer install时，Composer 优先读composer.lock，忽略composer.json中的版本约束 - 只有执行
composer update或首次无 lock 文件时，才按composer.json解析并生成/更新composer.lock - 团队协作中，
composer.lock必须提交进 Git，否则每人install出来的环境可能不一致
怎么生成或更新 composer.lock
生成 lock 文件不是独立命令，而是 composer install 或 composer update 的副产物。区别在于触发条件和行为：
- 项目首次初始化：删掉
composer.lock，运行composer install→ 自动根据composer.json生成新 lock - 想升级依赖：运行
composer update→ 重新解析所有约束，更新 lock 并安装新版本 - 只更新某一个包：用
composer update vendor/package-name，比如composer update phpunit/phpunit - 想强制重装当前 lock 记录的版本（比如换机器部署）：确保 lock 存在，直接
composer install
常见锁失效场景和坑
看似有 composer.lock，但实际没锁住，多是因为操作不当或理解偏差：
- 误删
composer.lock后只运行composer install—— 它不会报错，但会静默生成新 lock，版本可能漂移 - CI/CD 流程里用了
composer install --no-lock—— 这个 flag 会跳过 lock 校验，等同于退化成 update 行为 -
composer.json里写了"min-stability": "dev"或"prefer-stable": false—— 即使 lock 存在，某些包仍可能被解析成 dev 分支 - 手动编辑
composer.lock—— Composer 不校验手工修改，下次update或install会被覆盖，且易出格式错误
怎么确认当前到底锁的是哪个版本
别猜，直接看文件或命令输出：
- 打开
composer.lock，搜索包名，找"version"字段，比如"version": "v2.9.2" - 运行
composer show vendor/package-name，输出里versions行显示的是 lock 中记录的版本，不是composer.json约束 - 部署前加一道检查：
composer install --dry-run，它会模拟安装过程，告诉你是否要变更包版本
lock 文件不是“生成出来就完事”的产物，它是 Composer 工作流里唯一可信的版本事实源。只要它存在、没被绕过、没被手改，版本就是稳的——其余所有操作，都是在跟它对齐或更新它。
