必须提交composer.lock到Git，它是依赖树的精确快照，记录各包版本、校验和及安装方式；不提交则composer install退化为update，导致各环境vendor目录不一致。
为什么 composer.lock 必须提交到 Git 仓库
不提交 composer.lock，团队成员和 CI 环境每次运行 composer install 都会拉取不同版本的依赖，哪怕 composer.json 没变。这直接导致“在我机器上是好的”这类问题——根本不是代码问题，而是依赖版本漂移。
关键点在于：composer install 只读 composer.lock 安装确定版本；composer update 才按 composer.json 解析并更新锁文件。所以锁文件是生产一致性的唯一锚点。
-
composer.lock必须加入 Git，且不应出现在.gitignore中 - CI/CD 流程必须用
composer install --no-dev（或根据环境加--prefer-dist），而非update - 本地开发中，除非明确要升级依赖，否则不要随意执行
composer update
解决依赖冲突时，composer update 和 composer require 的行为差异
冲突常发生在多人修改 composer.json 后合并，或某人执行了 update 但没同步锁文件。这时不能只靠 git pull 拉代码，还必须让 Composer 感知变更。
composer require 是安全的“增量操作”：它只添加/更新指定包，并自动重算整个依赖图、更新 composer.lock；而 composer update 默认更新所有包（除非加包名参数），容易引入非预期升级。
- 新增一个包，优先用
composer require vendor/package，它会校验兼容性并写入 lock - 修复冲突时，先
git checkout -- composer.lock回退本地锁文件，再composer install强制对齐远程 lock - 若必须
update，请限定范围：composer update vendor/package --with-dependencies，避免全量刷新
CI 环境中 composer install 失败的常见原因与检查项
CI 报错 “Your requirements could not be resolved” 或 “Package X has a PHP requirement incompatible with your PHP version”，往往不是 Composer 本身问题，而是环境与锁文件不匹配。
核心矛盾点：锁文件里记录的包版本，可能依赖特定 PHP 版本、扩展或平台配置（如 ext-gd），而 CI 的 PHP 环境没对齐。
- 检查 CI 的 PHP 版本是否与
composer.json中"config": {"platform": {"php": "8.1.0"}}或"require": {"php": "^8.1"}一致 - 确认 CI 是否安装了锁文件中包所依赖的扩展（如
ext-imagick） - 避免在 CI 中使用
composer update—— 它绕过 lock 文件，等同于放弃版本控制 - 如果 CI 使用缓存，确保缓存键包含
composer.lock的 hash，而不是只看composer.json
多人协作时如何避免 composer.lock 合并冲突
composer.lock 是 JSON，Git 能合并，但结构复杂，手动修容易出错。最稳妥的方式是“谁改依赖，谁负责更新锁文件并推送”，而不是把锁文件当作次要产物忽略。
冲突通常出现在两个分支各自执行了 composer require 或 update，然后合并时 lock 文件内容不一致。此时 Git 会标出冲突块，但直接编辑 JSON 极易格式错误或漏字段。
- 发生冲突时，先
git reset --hard HEAD回退，再git pull origin main拉最新主干 - 然后重新执行你原本想做的操作（如
composer require foo/bar），让 Composer 自动重生成 lock - 如果必须保留两个分支的依赖变更，先
composer update拉通所有依赖，再composer install确保 lock 一致 - 建议在 PR 描述中注明“本次修改涉及依赖变更”，提醒 Reviewer 检查
composer.lock差异
锁文件不是“中间产物”，它是依赖状态的权威快照。只要有人跳过它、覆盖它、或者在不同环境中无视它的约束，冲突就不是偶然，而是必然。
