composer.lock 必须提交到 git，它是保证团队开发、测试、生产环境依赖一致的唯一可靠依据；不提交会导致各环境安装版本不一致，引发难以回溯的线上问题。
为什么 composer.lock 必须提交到 Git？
不提交 composer.lock，团队里每个人 composer install 装出来的依赖版本很可能不一致——哪怕 composer.json 里写的是 "monolog/monolog": "^2.0"。因为 Composer 会按当前最新可用版本解析，而这个“最新”每天都在变。
提交 composer.lock 后，composer install 就只按锁定文件装，跳过版本解析；只有执行 composer update 才会重新计算并更新 lock 文件。
- CI/CD 流水线必须依赖
composer.lock才能保证构建可重现 - 本地开发、测试环境、线上部署三者依赖一致的唯一可靠依据就是它
- 不提交 lock 文件，等于把“依赖一致性”交给运气
composer install 和 composer update 到底该用哪个？
日常开发中，95% 的场景该用 composer install：它读 composer.lock，装指定版本，快、确定、无副作用。
composer update 是“重算依赖树”的操作，会改 composer.lock，甚至可能升级次要版本（比如从 2.8.1 升到 2.9.0），带来兼容性风险。
- 新增/修改
composer.json后，先git add composer.json，再运行composer update xxx（指定包）或composer update（全量），然后git add composer.lock - 不要在 CI 脚本里写
composer update，除非你明确要刷新依赖 - CI 中应始终用
composer install --no-interaction --no-progress，避免意外触发 update
多人协作时 composer.lock 冲突了怎么办？
冲突本身不可怕，可怕的是随便选一边合并。lock 文件是完整依赖图的序列化结果，手动删行或凑合合并大概率导致依赖不一致或安装失败。
正确做法是放弃冲突解决，靠 Composer 重建：
- 先
git checkout --theirs composer.lock或git checkout --ours composer.lock（任选其一还原） - 删掉
vendor/目录和临时 lock 文件（确保干净） - 运行
composer install—— 它会基于当前composer.json和已有的 lock（或报错提示缺失 lock）重新生成一份 - 如果提示 “Your lock file does not contain a compatible set of packages”，说明
composer.json已被他人改动，此时应先git pull拉取最新，再composer install
要不要把 vendor/ 提交进 Git？
不要。绝对不要。
vendor/ 是构建产物，体积大、易变、含平台相关二进制（如 ext-redis 的 so 文件），Git 无法有效 diff，还会拖慢克隆和检出速度。
- 确保项目根目录有
.gitignore，且包含/vendor/这一行 - 如果历史误提交过
vendor/，需用git filter-repo清理，否则仓库会一直臃肿 - 某些离线环境确实需要打包 vendor，那是部署阶段的事，不是 Git 管理范畴
composer update 又不提交，或者删了 lock 再 install，整个团队的依赖一致性就塌了一角——这种问题往往要等到线上报错才暴露，而且很难回溯。 
