换镜像不能解决composer.lock冲突，因其仅加速元数据下载，不改变依赖解析逻辑；冲突根源是不同环境（php版本、platform配置等）下生成的依赖快照不一致，必须统一composer.json后执行composer update --lock重建锁文件。
换镜像不会解决 composer.lock 冲突，它只是加速元数据下载；冲突本质是多人修改了 composer.json 后各自生成了不一致的依赖快照，必须丢弃旧 composer.lock、统一 composer.json、再用 composer update --lock 重建。
为什么换阿里云/腾讯云镜像后 lock 还冲突
镜像源只影响包下载地址和 packages.json 元数据拉取速度，不影响 composer.lock 的生成逻辑。两个分支在不同时间、不同 PHP 版本、不同 Composer 版本下执行 composer update，哪怕用同一镜像，也会产出哈希不同的 composer.lock——因为 content-hash 包含 composer.json 内容、平台约束（如 config.platform.php）、甚至字段顺序。
- Git 合并时残留
标记 → 直接 JSON 解析失败 - 手动删标记但没清空 vendor →
composer install仍尝试复用损坏的缓存 - CI 中用了
--ignore-platform-reqs，本地却没用 →platform-check哈希不匹配，composer update --lock拒绝生成新锁
冲突发生后必须执行的三步操作
不是“选一方保留”，而是彻底重建。任何文本合并或 git checkout --ours 都会破坏 content-hash 绑定关系，导致后续 composer install 静默装错包。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确保
composer.json已 clean merge：用git checkout --theirs composer.json或手动整合增删项（尤其注意require、require-dev、config.platform.php） - 删掉当前
composer.lock和vendor/（避免旧缓存干扰） - 运行
composer update --lock：它不读旧 lock，只基于当前composer.json重算全部哈希与依赖树
预期输出是 Lock file operations: 0 installs, 0 updates, 0 removals；如果出现大量 Updating xxx，说明 composer.json 还没真正对齐，得先 git pull origin main 再来。
CI 流水线中防止 lock 冲突的关键配置
GitLab CI 或 GitHub Actions 里，不能依赖全局或宿主环境的镜像设置，否则不同 job 可能用不同源解析出不同依赖路径，加剧 lock 不一致。
- 在
.gitlab-ci.yml或workflow中显式重置镜像：composer config --global --unset repos.packagist+composer config repositories.packagist composer https://mirrors.aliyun.com/composer/ - 禁用
--ignore-platform-reqs：它掩盖 PHP 版本/扩展差异，让composer.lock缺失platform-check字段，导致本地和 CI 的 content-hash 天然不等 - 固定 PHP 镜像版本：比如
image: php:8.2-cli，避免因 runner 自带 PHP 小版本浮动（8.2.22 vs 8.2.25）触发 lock 重写
最易被忽略的是：哪怕你把镜像切得再快、并发调得再低、文件锁加得再严，只要 composer.json 里 "php": "8.2" 和 CI 中实际 php -v 输出不一致，composer update --lock 就永远无法生成可复现的合法 lock。
