不能。Composer 管理 PHP 包依赖，Git Submodule 管理源码级嵌套仓库；二者职责不同，不可替代：Composer 不感知 .gitmodules，不执行 submodule 命令，强行替代会导致版本失控、CI 构建失败及调试困难。
Composer能不能直接替代Git Submodule管理共享代码
不能。Composer 和 Git Submodule 解决的是不同层面的问题：Composer 管理的是 PHP 包级依赖，git submodule 管理的是源码级嵌套仓库。强行用 Composer 替代 git submodule 会导致版本失控、调试困难、CI/CD 构建失败等实际问题。
常见错误现象包括：
- 本地开发时
composer install成功，但部署到云函数或容器后因缺少.git目录导致子模块未拉取，运行时报Class not found - 多个微服务引用同一 Composer 包的
dev-master，某次composer update意外升级了不兼容的 commit，引发线上行为不一致 - 想在共享库中快速调试并提交修复，却发现必须先
git push到远程、再composer update、再测试，反馈链路过长
为什么用 Composer + path repository 能绕过 submodule 的坑
关键在于把共享代码当作“本地开发源”而非“远程包”，用 "type": "path" 显式声明依赖路径，让 Composer 直接软链接（symlink）而不是复制文件。这样既保留 Composer 的自动加载和依赖解析能力，又避免了 git submodule 的初始化复杂性。
实操建议：
alfred-github-backup
下载
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
- 在主项目
composer.json中添加："repositories": [ { "type": "path", "url": "../shared-utils" } ], "require": { "myorg/shared-utils": "*" } -
shared-utils目录必须是独立 Git 仓库，且含有效composer.json（含name和autoload） - 执行
composer install后，vendor/myorg/shared-utils是指向../shared-utils的符号链接，修改即实时生效 - CI/CD 中需确保构建机上存在该路径，或改用
git clone --recursive+composer install --no-dev组合
混合使用 Composer 和 git submodule 的真实场景
当共享代码本身又依赖第三方 Git 仓库（比如封装了某个私有 SDK），而该 SDK 又用了 git submodule，这时单纯靠 Composer 无法触发子模块拉取——因为 composer install 不执行 git submodule update。
必须手动补全：
- 在项目根目录
composer.json的scripts中加入："post-install-cmd": [ "@php -r \"if (is_dir('.git')) { system('git submodule update --init --recursive 2>/dev/null || true'); }\"" ] - 仅对通过
"type": "vcs"方式引入的包生效；若用path类型，则无需此脚本 - 生产环境部署若删掉了
.git目录（如git archive打包），该脚本自动跳过，不会中断流程
微服务间共享代码最易被忽略的边界点
不是怎么引入，而是怎么隔离变更影响。比如 shared-utils 里一个 JsonHelper::encode() 方法加了新参数，默认值为 null，看似向后兼容——但若某个微服务恰好用了 declare(strict_types=1)，调用时没传参就会直接报 TypeError。
真正需要卡住的点是：
- 所有共享库必须声明
minimum-stability为stable，禁止dev-master直接上线 - 每个微服务的
composer.lock必须提交，且 CI 流水线校验其 hash 是否与主干一致 - 共享库的每次 tag 发布，都应触发下游所有微服务的自动化兼容性测试（哪怕只是
php -l扫描）
