composer.lock 冲突不应手动修改，而应通过 composer install/update 重建；若仅增删包或微调PHP约束，可弃用分支lock并重装；关键依赖升级需谨慎；务必确保 composer.json 无冲突、禁用Git自动合并、变更后运行 dump-autoload。
composer.lock 冲突时别手动改，先看它是不是真的需要合并
绝大多数 composer.lock 合并冲突其实不该手动解决——因为这个文件本该由 composer install 或 composer update 生成，不是人写的。Git 报冲突，往往只是两个分支各自运行过 composer update 或增删了包，导致哈希、版本、依赖树不一致。
判断是否真要合并：如果两边改动都只是新增/删除同一类包（比如都加了 monolog/monolog），或只是 PHP 版本约束微调，那大概率可以直接放弃当前分支的 composer.lock，用主干的重装；但如果某边升级了关键依赖（如 laravel/framework 从 v10 到 v11），就得小心了。
- 检查冲突前先
git status，确认只有composer.lock冲突，composer.json没冲突——否则得先理清composer.json的差异 - 运行
composer show --outdated看当前 lock 是否已过时，避免在旧 lock 上强行合并 - 别直接删 lock 文件再
composer install——这会忽略 dev 依赖和平台配置，可能装出和 CI 不一致的环境
用 composer merge-plugin 还是纯命令行？选后者更可控
composer-merge-plugin 早就不维护了，且它试图“合并” lock 文件逻辑本身就有问题：lock 不是配置，是快照。官方明确不支持多源 lock 合并。现在推荐用 Git + Composer 协作流程来绕过合并需求。
- 开发时尽量避免在 feature 分支里跑
composer update，只做composer require xxx或composer remove xxx，这些操作会自动更新 lock，且变更集中、可读 - 合入主干前，在 feature 分支上执行
composer update --lock（不改依赖，只同步 lock 哈希），再提交——这样 lock 变更更干净 - 如果已冲突，最稳做法是：暂存当前 lock → checkout 主干 lock →
composer install→ 再按需composer require/remove恢复本分支的依赖变更 → 生成新 lock
CI/CD 中 lock 文件冲突导致构建失败？关键在 .gitattributes 配置
很多团队 CI 失败是因为 Git 把 composer.lock 当普通文本处理，用了默认合并策略，结果产出非法 JSON。这不是 Composer 的锅，是 Git 没配对。
- 在项目根目录加
.gitattributes，写一行：composer.lock merge=ours—— 表示发生冲突时无条件采用当前分支的版本（适合主干优先策略） - 或者更保守点：
composer.lock -diff -merge，彻底禁用 diff 和 merge，让 Git 报错而不是瞎合，逼开发者走正确流程 - GitHub Actions / GitLab CI 中，确保
composer install前没有残留的vendor/或部分写入的 lock，否则会静默跳过安装或报Root package 'xxx' cannot be found in vendor/
“冲突解决了但 autoload 失效”？检查 vendor/composer/installed.php 和 classmap
看起来 lock 合并成功、composer install 也过了，但 Class not found，八成是 autoloader 没刷新。Composer 的 autoload 信息存在 vendor/composer/installed.php 和 vendor/composer/autoload_classmap.php 里，这两个文件不会随 lock 变动自动重建。
- 每次 lock 变更后，必须重新运行
composer dump-autoload（尤其加了--optimize或--classmap-authoritative时） - 如果用了 PSR-4 映射，确认
composer.json里"autoload"段没被合并搞乱缩进或逗号——JSON 语法错误会导致installed.php为空 - 本地测试时，删掉整个
vendor/和composer.lock，只留composer.json，再composer install，这是验证 lock 是否真正自洽的黄金步骤
lock 文件真正的复杂点不在结构，而在它隐式绑定了 PHP 版本、扩展、平台配置、甚至 packagist 镜像状态。一次看似简单的合并，可能让本地能跑、CI 报错、预发环境 classmap 缺失——所有这些，源头都是把它当文本去“合并”，而不是当产物去“重建”。
