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），带来兼容性风险。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 新增/修改 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 管理范畴

lock 文件不是“可选附件”，它是 Composer 项目事实上的依赖契约。只要有人绕过它直接 composer update 又不提交，或者删了 lock 再 install，整个团队的依赖一致性就塌了一角——这种问题往往要等到线上报错才暴露，而且很难回溯。