composer不支持合并多个composer.json，merge-plugin已彻底失效；正确做法是人工核对require/require-dev/scripts/extra字段，用模板脚本生成或repositories引入私有包，确保最终只有一个有效composer.json。

composer merge-plugin 已彻底失效，别再用它合并配置。 它在 Composer 2.2+ 中被完全移除，启用后直接报错 Plugin merge-plugin could not be initialized；即使降级到旧版 Composer，也会出现 require 被覆盖、autoload 映射丢失、extra 字段静默清空等不可控问题。所谓“自动合并”，实际是浅层 JSON 合并，不理解 Composer 的依赖语义和 autoload 规则。

Composer 本身根本不支持多文件合并

Composer 只读取项目根目录下唯一的 composer.json，不解析、不比较、不融合任何其他 JSON 文件。你看到的“多个配置”场景，本质是人为维护多份（比如模块目录下的 composer.json），但 Composer 对它们完全无感。

• 运行 composer install 或 composer update 时，Composer 基于内存中构建的完整依赖图重写整个 composer.json，不会保留你手写的 scripts、config、extra 结构
• composer.lock 是单项目快照，两个项目的 lock 文件拼在一起等于喂给 SAT 求解器一团乱麻，必须删掉重建
• 所谓“冲突”，往往来自 git merge 自动处理了 composer.json，但没人工核对 require-dev 里同名包的版本约束是否互斥（例如一个要 "laravel/framework": "^10.0"，另一个写 "^11.0"）

require / require-dev / scripts 字段必须人工核对

这三个位置无法靠工具安全合并，必须逐项检查：

Pandas 配置文件报告生成器

使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

下载

• require 和 require-dev：同名包若版本范围无交集（如 "monolog/monolog": "^1.0" vs "^3.0"），Composer 会直接拒绝安装；需手动选一个，或找中间兼容版本（如 "^2.0"）
• scripts：同名 script（如 "post-install-cmd"）会被后定义的覆盖；建议统一改用数组写法："post-install-cmd": ["@php artisan optimize:clear", "npm run build"]
• extra：格式自由、无规范约束；两个项目都定义了 "laravel-ide-helper": {"include": []}，就得手动去重或按环境条件加载

替代方案只有这几种可行路径

所有方案核心逻辑一致：确保最终只有一个有效、语义正确的 composer.json。

• 用模板 + 脚本生成：比如用 jq 或 PHP 脚本读取多个源 JSON，按规则合并字段后输出最终 composer.json，再运行 composer install
• 用 repositories 引入私有包：把模块拆成独立 Composer 包，通过 type: package 或私有 Packagist 注册，主项目只 require 它们
• 用 config.platform + 环境变量控制行为：比如在 CI 中注入 COMPOSER_PLATFORM_CHECK=0 绕过平台检查，或用 platform.php 固定 PHP 版本
• 彻底放弃“分散配置”思路：把扩展逻辑移到包内（如 MediaWiki 扩展自带 composer.json），由主项目显式 require，而非试图动态合并

真正容易被忽略的是 minimum-stability 和 prefer-stable 字段。一个项目设 "minimum-stability": "dev"，另一个是默认 "stable"，合并后不显式统一，可能导致 dev-main 包意外装上——这种问题不会报错，但会在生产环境引发难以追踪的异常。