composer不是微服务拆分工具，它只解决php包依赖与自动加载问题；真正拆分需明确业务边界、数据归属和运行时契约，而composer仅支持通过抽离高内聚模块为独立包实现渐进式重构。
Composer 不是微服务拆分工具，它只管 PHP 包依赖
Composer 本身不参与服务拆分、进程隔离或网络通信，它只解决“代码怎么组织、怎么加载”的问题。你不能靠 composer install 把单体应用变成微服务——那只是把一堆类文件装进 vendor 目录而已。真正要拆的是业务边界、数据归属和运行时契约。
但 Composer 在平滑迁移中确实能起关键作用：它让你把原单体里高内聚的模块（比如认证逻辑、通知发送器）抽成独立包，再通过 require 声明依赖，而不是硬编码 include 或直接复制粘贴。这样既能保留旧系统运行，又能为后续服务化铺路。
- 拆包前必须确认该模块是否具备“可独立演进”特征：有清晰输入输出、无全局状态、不直连其他模块数据库表
- 每个新包应声明自己的
autoload规则，避免污染主应用命名空间；例如"psr-4": {"App\Auth\": "src/"} - 不要急于删掉原单体里的对应代码——先用
class_alias()或代理类维持兼容，等调用方全部切到新包后再清理
如何用 Composer 实现“边跑边拆”的渐进式重构
核心思路是让新包和旧代码共存，通过 Composer 的自动加载机制控制流向，而不是一次性替换。典型场景是把用户认证模块从单体中剥离：
- 新建
acme/auth-service包，实现AuthenticatorInterface，提供login()和validateToken()方法 - 在原单体项目的
composer.json中添加"acme/auth-service": "^1.0"，并执行composer update - 修改原单体中调用认证的地方，从直接 new Class 改为通过容器解析接口：
$auth = $container->get(AuthenticatorInterface::class) - 初期实现仍指向原单体类；等新包功能稳定后，再切换绑定到新包里的实现类
这个过程不中断线上服务，也不要求所有团队同步改造，适合多人协作的遗留系统。
容易踩的坑：共享类名、循环依赖、autoload 冲突
最常见错误不是语法问题，而是 Composer 加载机制被误用导致行为不可控：
-
class_exists('UserRepository')可能返回 true，但实际加载的是旧单体路径下的类，而非新包里的同名类——检查composer dump-autoload -p输出的映射顺序 - 两个包互相
require对方，形成循环依赖；此时 Composer 会报错Dependency resolution failed，必须引入中间抽象包或改用运行时服务发现 - 多个包都声明了
psr-4映射到App\，导致类加载冲突；解决方案是强制限定命名空间前缀，如"acme/user-core": "src/UserCore/" - 忘记在新包里定义
minimum-stability或prefer-stable，导致开发环境拉取 dev-main 分支引发不稳定
什么时候该停用 Composer，转向真正的服务化？
当你的包之间开始出现以下信号，说明已超出 Composer 能力边界，该上 HTTP/gRPC 了：
- 某个包频繁读写另一个包的数据库表（比如
acme/order-service直接查acme/user-service的 users 表） - 包之间通过全局变量或静态方法传递上下文（如
UserContext::setTenantId()），无法跨进程复现 - 为了绕过 Composer 加载限制，开始在代码里写
file_get_contents('http://user-api/v1/profile')这类硬编码调用 - CI 流程里需要同时构建、测试、部署多个包，但它们共享同一套配置和日志路径，根本没法独立发布
这时候，composer require 就该换成 docker-compose up -d user-api order-api 了。Composer 完成了它的使命：把边界理清楚，把代码解耦开，剩下的交给网络和协议。
