Composer不支持Git Submodule，需手动初始化子模块或通过脚本自动化处理，推荐将子模块内容提交至主库或改用git subtree以避免复杂性。
Composer 本身并不直接支持 Git Submodule 作为依赖管理方式。它主要依赖于 Packagist 和 Composer 仓库来解析和安装 PHP 包，而 Git Submodules 是 Git 层面的功能，用于将一个 Git 仓库嵌套在另一个 Git 仓库中。因此，在使用 Composer 管理项目时，若涉及到 Git Submodule 类型的依赖，需要结合手动操作与合理的配置策略。
理解 Git Submodule 与 Composer 的关系
Git Submodule 允许你将一个 Git 项目作为子目录引入到另一个 Git 项目中，并保持各自的版本控制独立。但 Composer 不会自动初始化或更新这些子模块。如果你的项目或某个依赖使用了 submodule，必须在执行 composer install 或 update 后手动处理 submodule。
- Composer 安装的是通过 composer.json 声明的包，不会解析 git submodule 配置
- 如果主项目包含 submodule，需在克隆后运行 git submodule update --init --recursive
- 如果第三方库以 submodule 形式存在，不能直接通过 require 添加进 composer.json
在项目中使用含 submodule 的库
当你的项目依赖某个使用了 Git Submodule 的第三方库（例如该库源码托管在 GitHub 并依赖子模块），标准做法不是让 Composer 处理 submodule，而是确保该库发布到 Packagist 的版本已经包含了必要的文件（即子模块内容已被“快照”提交）。
- 推荐库作者在打 tag 时将 submodule 内容实际提交进主仓库（避免依赖 git 操作）
- 这样 Packagist 抓取的 zip 包中已包含所有代码，用户无需执行 git submodule 命令
- 否则使用者必须从 git 安装（"type": "git" + repositories），并手动初始化 submodule
私有库或开发中使用 submodule 的方案
对于内部项目或开发阶段，若必须使用带 submodule 的库，可以通过自定义仓库类型配合脚本实现自动化。
- 在 composer.json 中添加 repository 指向私有 Git 地址
- 设置安装类型为 "vcs"
- 利用 Composer 脚本钩子（scripts）在 post-install-cmd 或 post-update-cmd 中执行 submodule 更新
{
"scripts": {
"post-install-cmd": [
"git submodule update --init --recursive"
],
"post-update-cmd": [
"git submodule update --init --recursive"
]
}
}
注意：此方法要求部署环境支持 git 命令且具备相应权限。
替代建议：避免依赖 submodule 的复杂性
为了提升可维护性和部署便利性，建议尽量避免在 Composer 包中使用 Git Submodule。
- 将共用组件发布为独立的 Composer 包，通过 require 引入
- 使用 CI/CD 流程在打 tag 前自动拉平 submodule 内容
- 考虑使用 git subtree 将外部项目合并进本地分支，不再保留 submodule 结构
