提交composer.lock引发问题怎么处理？团队协同提交规范-composer-PHP中文网

提交 composer.lock 后 ci 失败或本地报错，根本原因是 lock 暴露了隐藏不一致：如 composer.json 未同步更新、php 版本/扩展不匹配或 platform 配置被忽略；常见报错包括依赖无法解析、class not found 或版本冲突。

提交composer.lock引发问题怎么处理？团队协同提交规范

为什么提交 composer.lock 后反而 CI 失败或本地报错？

根本原因不是 lock 文件本身有问题，而是它暴露了更早埋下的不一致：比如某人运行了 composer update 但没同步 composer.json，或 PHP 版本配置未对齐，又或者 platform 设置被忽略。

常见现象包括：

Your requirements could not be resolved to an installable set of packages —— lock 文件里记录的包组合，在当前 PHP 环境下已不可用
CI 报 Class not found 或 undefined method —— lock 文件锁的是旧版依赖，但 composer.json 已悄悄升级了约束（如从 "monolog/monolog": "^2.0" 改成 "^3.0"），而 lock 没重生成
本地 composer install 成功，同事执行却失败 —— 对方 PHP 版本低于 lock 中某个包要求的最低版本（例如 lock 记录了只支持 PHP 8.1+ 的包，但对方用的是 8.0）

团队提交前必须验证的三件事

不能把 composer.lock 当普通文件一提交了事。每次修改依赖后、push 前，要确认以下三点是否闭环：

运行 composer validate —— 检查 composer.json 格式与语义是否合法
运行 composer show --platform —— 确认当前 Composer “认为”的 PHP 版本和扩展，和团队约定一致（不是 php -v 输出）
运行 composer install --dry-run —— 模拟安装流程，看是否能干净还原 lock 文件中所有依赖，不报错、不提示“需要更新”

这三步缺一不可。漏掉任意一个，就等于把隐患打包进 Git。

多人协作时，谁该提交新 lock 文件？

答案很明确：只有执行 composer update 的那个人，且必须在测试通过后立即提交。

Workflow Decomposer

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

下载

关键动作不是“谁点回车”，而是“谁负责验证影响范围”。这意味着：

禁止在 feature 分支上单独运行 composer update 并提交 lock —— 它可能和主干已有依赖冲突
所有依赖变更应合并在一个 PR 中，并附带说明：require 新增了什么、update 升级了哪些包、是否涉及 BC Break（比如 Symfony 6 → 7）
CI 流水线必须用 composer install（不是 update），并检查 git status --porcelain composer.lock 是否为空 —— 如果有未提交的 lock 变更，直接 fail

这个机制倒逼团队把依赖升级当成一次受控发布，而不是随手敲个命令。

lock 文件冲突了，为什么不能手动改？

因为 composer.lock 不是键值对配置，它是整个依赖图的完整快照：包含每个包的 dist.url、dist.shasum、source.reference、嵌套依赖的精确版本，甚至 autoloader 映射规则。手动删几行、保留“A 的版本”和“B 的哈希”，大概率导致 vendor/autoload.php 加载失败或类找不到。

正确做法只有一条路径：

先 git checkout --ours composer.json（或 --theirs），确保 composer.json 是双方合并后的最终版
删除本地 composer.lock 和 vendor/
运行 composer update --lock —— 注意不是 update，加 --lock 表示只更新 lock 文件，不改 vendor（适合已存在 vendor 但 lock 过期的场景）；若 vendor 也脏了，直接 composer update
提交新生成的 composer.lock