核心是「一次只改一个地方，且改完立刻固化」：所有依赖变更须在独立分支完成，提交必须同时包含 composer.json 和 composer.lock；冲突时删 lock 文件并运行 composer update --lock 重建，不可手动编辑 conflict 标记。
怎么让 composer.json 变更不引发 lock 文件冲突
核心是「一次只改一个地方，且改完立刻固化」。多人同时在不同分支执行 composer require 或 composer update，会导致 composer.json 和 composer.lock 各自产生不一致的修改，Git 合并时必然冲突。
实操建议：
- 所有依赖变更（增删改）必须在独立功能分支完成，提交前确保
composer install成功、vendor/可运行 - 变更提交必须包含
composer.json和composer.lock两个文件，不可只提一个 - 避免在开发分支长期不合并主干——差异越大，
composer.lock的哈希和依赖路径越难对齐 - CI 流水线中固定用
composer install --no-interaction，不跑update，靠 lock 文件保一致性
composer.lock 冲突了，为什么不能手动删 conflict 标记
因为 composer.lock 不是普通 JSON，而是带哈希校验、嵌套依赖树、平台约束等结构的二进制语义快照。Git 冲突标记（）一旦混入，composer install 会直接报 Invalid lock file，连解析都失败。
真正有效的做法：
- 先
git checkout --ours composer.json或--theirs，选一个版本作为基础（推荐合并后的最终composer.json） - 删除本地
composer.lock和vendor/ - 运行
composer update --lock—— 它会按当前composer.json重新计算依赖树并生成新 lock - 若想最小化变更，加
--minimal-changes：composer update --lock --minimal-changes
为什么 prefer-stable 和 minimum-stability 要统一配置
团队里有人没配 "minimum-stability": "stable"，或漏设 "prefer-stable": true，就可能让 composer update 拉下 dev-main 或 beta 版本。这些版本不会出现在别人锁文件里，一合并，composer.lock 就全量重写，看似“解决”了冲突，实则引入了不稳定依赖。
检查与加固方式：
- 在
composer.json顶层显式声明："minimum-stability": "stable",<br>"prefer-stable": true
- 用
composer validate确保配置合法 - CI 中加检查：
composer config minimum-stability输出必须为stable - 禁止在
require-dev里用dev-前缀，改用^x.y+conflict拦截已知不兼容版
私有包更新后，为什么队友的 lock 文件总“失效”
私有仓库返回的元数据（packages.json）如果没同步更新版本号，或者没刷新 dist 包的 SHA256，Composer 就会认为「这个版本不存在」，转而回退找 Packagist 上的老版本——但你的 composer.lock 记的是私有源的 hash，队友 install 时就会因 hash 不匹配失败。
关键动作：
- 私有包发版后，立即触发仓库元数据重建（如 Satis rebuild 或 Private Packagist sync）
- 确认
composer show vendor/private-package输出中的source字段指向私有源，且dist的sha256与实际压缩包一致 - 团队共享的
repositories配置中，私有源必须带"canonical": false，否则它会阻断 Packagist 查找，导致其他公共包装不上 - 上线前跑一次
composer update --dry-run，看是否所有包都能 resolve 到预期源
复杂点在于：lock 文件不是“结果”，而是“契约”。它既反映当前依赖状态，也隐含了 PHP 版本、平台扩展、甚至私有仓库可用性等上下文。任何一方环境或配置漂移，都会让这份契约在别人机器上无法兑现。
