Composer项目配置合并冲突_Composer多环境配置版本协同法【方法】-composer-PHP中文网

composer不支持也不应合并多个composer.json文件，它只读取根目录下唯一配置；所谓“合并”实为配置收敛需求，正确解法是用私有包、repositories或环境变量统一管理，而非拼接json。

composer项目配置合并冲突_composer多环境配置版本协同法【方法】

Composer 不支持、也不应该合并多个 composer.json 文件。所谓“多环境配置合并”，本质是误把配置管理问题当成了文件拼接问题——你真正需要的不是合并，而是收敛。

Composer 只读取项目根目录下唯一的 composer.json，它不解析、不叠加、不识别任何“子配置”。所有试图用脚本或插件（比如已废弃的 merge-plugin）合并多个 JSON 的做法，都会导致：

autoload 字段被覆盖而非追加，PSR-4 映射丢失
require 和 require-dev 中同名包版本冲突，且 Composer 不做语义交集判断
scripts、extra 等非核心字段在重写时被静默丢弃
启用 merge-plugin 后，composer dump-autoload -o 报 Warning: Ambiguous class resolution 或直接失败

Composer 原生支持的顶层字段中，只有 config 和 extra 是安全可变的。它们不会影响依赖解析逻辑，也不会被其他命令覆盖：

Workflow Decomposer

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

下载

config.platform.php：用于锁定 PHP 版本，避免 CI 因本地 PHP 版本不同生成不一致的 content-hash
config.notify-on-install：开发环境开，生产关
extra 下自定义键（如 "env": "staging"）：供部署脚本读取，不参与 Composer 运行时逻辑
绝对不要在 extra 里嵌套复杂结构（如 {"build": {"steps": [...]}}），否则可能被某些 IDE 插件或 CI 工具误解析并清空整个 extra 字段

Git 合并时出现 composer.lock 冲突，90% 源于团队没对齐“谁有权更新依赖”这件事。它不是文本差异问题，而是快照不一致：

如果你在多个项目里重复写相同的 autoload 规则、scripts 或 config，正确路径是把它抽成一个独立的私有包：

新建包 myorg/composer-config-base，其 composer.json 中定义 "autoload": {"psr-4": {"App\": "src/"}}
主项目通过 "repositories" 引入该包，并 require 它（类型设为 "metapackage"）
所有 autoload、scripts、config 都由该包声明，主项目只需保持空的对应字段即可
升级配置 = 更新这个私有包版本，无需手动改每个项目的 composer.json