Monorepo中依赖管理需根据子项目生命周期选择方案：若需对外发布，开发时用Composer path实现快速联调，发布时通过git subtree push分离到独立仓库并更新依赖；若为私有共部署模块，则直接使用path仓库提升效率。核心在于判断子项目是否独立演进或对外暴露，据此平衡开发便捷性与发布需求。
在 Monorepo 项目中，多个包或子项目共享同一个代码仓库，但各自可能拥有独立的 Composer 依赖。如何高效管理这些依赖，是开发和部署中的关键问题。目前常见的方案包括使用 Git Subtree 和本地 Composer Path 仓库。两者各有适用场景，选择需结合团队协作、发布流程和依赖隔离需求。
Git Subtree：将子项目作为独立仓库嵌入主库
Git Subtree 允许你将一个外部 Git 仓库合并到当前仓库的某个子目录中，同时保留其提交历史。在 Monorepo 中，你可以将各个 PHP 包维护为独立仓库，再通过 subtree 方式集成进主库。
优点：
- 子项目保有独立版本控制，可单独克隆、测试和发布
- 支持双向同步：主库可拉取子项目更新，也可推送变更回原仓库
- 发布流程清晰，适合需要打 tag、发 Packagist 的组件化项目
缺点：
- 操作复杂，merge 和 push 需要额外命令（如 git subtree pull/push）
- 容易因操作不当导致历史混乱
- 开发时无法直接修改子项目并立即在主项目中生效，需频繁同步
适用于：子项目有独立生命周期，需对外发布，且团队熟悉 Git 高级操作。
Composer Path 仓库：本地路径映射实现即时依赖
利用 Composer 的 path 类型仓库，可在主项目的 composer.json 中直接引用 Monorepo 内部的子包路径。例如：
"repositories": [
{
"type": "path",
"url": "packages/my-package"
}
]
当执行 composer install 时，Composer 会软链接（或复制）该目录内容作为依赖安装。
优点：
- 开发体验极佳：修改子包后主项目立即可用，无需提交或同步
- 配置简单，只需一行声明
- 适合快速迭代的内部模块，尤其在 CI 中可通过 symlink 提升效率
缺点：
- 仅适用于本地开发或构建环境，不能用于公开分发
- 若子包需独立发布，仍需额外流程推送到 Git 并更新 Packagist
- 路径依赖易出错，重构目录结构时需同步调整
适用于：Monorepo 内部高度耦合的模块，无需对外发布，强调开发效率。
如何选择？看发布与协作模式
如果你的 Monorepo 中包含需要对外发布的公共库，比如 SDK 或通用组件，推荐结合使用两种方式：
- 开发阶段用 Composer path 实现快速联调
- 发布时从主库提取子目录，推送到独立仓库（可借助 git subtree push）
- 发布后更新主库依赖为对应版本号
如果所有子项目均为私有、共部署，不独立发布，则直接使用 path 仓库更简洁高效。
基本上就这些。关键是明确各子项目的边界和生命周期——是否独立演进、是否对外暴露。根据这一点，灵活组合策略，才能在统一管理和开发效率之间取得平衡。
