composer.lock冲突必须删掉重生成，不能手动合并；冲突表明依赖快照真实不兼容，手动修复99%导致install报错；唯一安全操作是先确保composer.json语义一致，再删lock并运行composer update --lock。
composer.lock冲突必须删掉重生成，不能手动合并
Git 标出 composer.lock 冲突时，说明两个分支的依赖快照已不可兼容——不是格式问题，而是 content-hash、dist.sha256、platform 字段或 packages 数组顺序真实不同。手动删冲突标记、拼接 JSON、调缩进或保留某一方内容，99% 会导致后续 composer install 报错，比如：JSON decode error: Syntax error、Package xyz has a mismatched hash，甚至静默装错子依赖，上线后才暴露类找不到。
冲突发生后只运行 composer update --lock
composer update --lock 是唯一安全操作：它不读旧 composer.lock，也不改 vendor/，只根据当前已合并干净的 composer.json 重算并写入新快照。执行前确保：
- 先用
git checkout --ours composer.json或git checkout --theirs composer.json选一个语义正确的版本，或手动整合新增包、PHP 版本约束等变更 - 删掉当前冲突的
composer.lock（可先mv composer.lock composer.lock.bak备份） - 运行
composer update --lock；理想输出是Lock file operations: 0 installs, 0 updates, 0 removals - 如果输出含大量
Updating xxx，说明composer.json还没真正拉齐，得先git pull origin main再重试
怎么让团队少遇到“假冲突”
很多所谓冲突其实只是字段顺序、空行或缩进差异导致的 Git 行级误报。预防比修复更有效：
- 在
composer.json的config段加"sort-packages": true，再跑一次composer update --lock提交，强制固定packages数组顺序 - 禁用
composer update全量更新；加依赖统一用composer require vendor/package --no-update，只改composer.json，最后由专人集中执行composer update --lock - CI 脚本里别用
--no-lock；第一步加ls -la composer.lock校验文件存在且时间戳匹配当前 commit
CI 和本地环境不一致？先看 platform 而不是 lock
同一份 composer.lock 在 CI 失败、本地却能跑通，大概率不是 lock 本身问题，而是环境快照不一致：
- 运行
composer show --platform，对比php、ext-intl、lib-curl等输出是否完全一致 - 若不一致，别急着重建 lock，先统一 Dockerfile 的 PHP 版本或 .php-version 文件
- 用
composer why-not vendor/package:2.1.0快速定位阻断源：A 机器报 requires php ^8.1，B 机器报 requires ext-gd，分歧点立刻浮现
真正难处理的从来不是冲突本身，而是有人在没确认 composer.json 语义一致的前提下，就去动 composer.lock 或跑 composer install —— 这会让问题从“可重建”变成“需溯源”。
