Composer 本身无 split 命令，拆分依赖 Git 工具（推荐 git filter-repo），Composer 仅负责加载已发布的独立包；子包需规范 name、autoload、repositories 配置，否则类找不到或 CI 失败。
Composer 本身没有 split 命令，所谓 “Composer split 工具” 实际是误传——真正起作用的是 Git 工具（如 git subtree 或 git filter-repo），而 Composer 只负责后续的包加载与依赖解析。直接在 monorepo 里运行 composer split 会报错或无响应。
为什么不能用 Composer 自带命令拆分？
Composer 是依赖管理器，不是代码切分工具。它不读取目录结构、不重写 Git 历史、不移动文件。所谓 “split 子包”，本质是把 monorepo 中某个子目录（如 packages/http-client）单独拎出来，变成一个有自己 Git 历史、独立 composer.json、可被其他项目 require 的包。这个过程必须由 Git 层完成。
-
composer命令列表里根本没有split、extract或subtree子命令 - 试图运行
composer split会提示Command "split" is not defined - 所有“拆分后能被 Composer 加载”的效果，都依赖你先用 Git 工具导出子仓库，再确保其
composer.json符合规范
实际该用哪个 Git 工具？git subtree 还是 git filter-repo？
优先选 git filter-repo，git subtree 仅适用于简单、低频场景。前者能干净剥离历史、重写路径、保留提交元数据；后者会在主仓库留下冗余合并提交，且难以回滚。
-
git subtree：适合临时导出、不关心历史纯净度、团队不熟悉新工具的情况。命令形如git subtree push --prefix=packages/http-client origin http-client，但会污染主分支历史 -
git filter-repo：推荐用于生产级拆分。执行git filter-repo --subdirectory-filter packages/http-client --force后，当前仓库只剩http-client目录内容，且所有提交路径已重写为根目录，可直接推送到新仓库 - 注意：
git filter-repo会重写整个仓库历史，操作前必须备份，且所有协作者需重新 clone
拆完之后，Composer 怎么认这个新包？
不是“Composer 认”，而是你要让 Composer 能定位并解析它——关键在 composer.json 的 name 字段和主项目的 repositories 配置。
- 子包的
composer.json必须含全局唯一"name": "myorg/http-client"，不能是"name": "http-client"或相对路径名 - 主项目若要试用该包，需在自己的
composer.json中声明repositories指向新 Git 仓库：{ "repositories": [ { "type": "vcs", "url": "https://github.com/myorg/http-client" } ], "require": { "myorg/http-client": "dev-main" } } - 禁止继续用
"type": "path"指向本地 monorepo 子目录——这会导致循环依赖或版本不可控，CI 构建失败率极高
最容易被忽略的三个点
拆分成功 ≠ 包可用。以下三处不处理，90% 的团队会在上线前一小时发现类找不到：
- 子包的
autoload必须显式声明psr-4，且命名空间前缀要匹配name字段（如"myorg/http-client"对应"MyOrg\HttpClient\": "src/"），不能沿用原 monorepo 的App前缀 - 子包若依赖 monorepo 内其他模块（如
http-client依赖http-contract），这两个包必须各自发布、各自声明真实包名，绝不能在composer.json里写"require": {"../contracts": "*"} - 主项目中所有对原路径的
use、new、配置项、服务提供者注册，必须全部替换为新包的命名空间和接口，composer remove不会帮你扫这些
