Composer虽不原生支持Monorepo，但可通过为每个应用/包设独立composer.json、根目录仅管开发依赖、PSR-4自动加载跨包引用、各vendor隔离等策略高效管理。
Composer 本身不原生支持 Monorepo，但可以通过合理组织 composer.json 文件、自定义自动加载规则和调整依赖解析策略，在 Monorepo 中高效管理多个独立应用（如 Web 应用、CLI 工具、API 服务等）。
每个应用/包拥有独立的 composer.json
在 Monorepo 中，不要只在根目录放一个全局 composer.json。而是为每个逻辑上独立的应用或可复用的包（例如 apps/admin、apps/api、packages/logging）分别维护自己的 composer.json。这样能确保：
- 各应用可声明专属依赖（如 Laravel vs Symfony），互不干扰
- 发布时可单独打包、打 tag、提交到 Packagist（如果需要）
- CI 可按需安装指定应用的依赖（
cd apps/api && composer install）
统一管理共享依赖与开发工具
在根目录保留一个 composer.json，仅用于集中管理所有子项目共用的开发依赖（如 PHPStan、PHP-CS-Fixer、PHPUnit、infection）和脚本命令。它不声明业务依赖，也不被任何应用直接 require。示例结构：
{
"name": "myorg/monorepo",
"type": "project",
"require-dev": {
"phpunit/phpunit": "^10.5",
"phpstan/phpstan": "^1.11",
"friendsofphp/php-cs-fixer": "^3.14"
},
"scripts": {
"test": "phpunit --configuration apps/admin/phpunit.xml",
"cs-fix": "php-cs-fixer fix packages/logging/src/"
}
}
这个根 composer.json 的作用是提升开发体验，而非运行时依赖中心。
通过 PSR-4 自动加载实现跨包引用
当某个应用需要使用 Monorepo 内另一个包（如 apps/web 用 packages/auth），不要用 path 仓库 + repositories 配置——那会破坏本地开发一致性。推荐方式是：
- 在应用的
composer.json中，用"autoload": {"psr-4": {...}}显式包含目标包的源码路径（仅限本地开发） - 同时在
"autoload-dev"或 CI 构建阶段，通过 Composer 的path类型仓库临时映射（用于测试集成） - 正式发布前，将
packages/auth发布为独立包，并在应用中切换为版本化 require（如"myorg/auth": "^2.0"）
这样兼顾了本地快速迭代与生产环境的稳定性。
避免自动加载冲突与依赖爆炸
多个 composer.json 并存容易导致：
- 同一类库在不同应用中版本不一致（如 Guzzle 7.4 vs 7.8）
- 根目录
vendor和子目录vendor混乱（不推荐共用 vendor） - IDE 或静态分析工具无法准确定位类来源
解决办法：
- 禁止在根目录运行
composer install；所有vendor必须位于各自应用/包目录下 - 用
composer show --tree定期检查关键应用的依赖图谱，识别隐式升级风险 - 在
.gitignore中明确忽略所有**/vendor/，防止误提交
