composer不解决强耦合，只放大已有耦合；它唯一能守住的是依赖隔离底线，真终结强耦合需服务边界划分、通信契约与依赖隔离协同。
composer 不解决强耦合，它只放大你已有的耦合设计。真正在微服务里终结强耦合的，是服务边界划分 + 通信契约 + 依赖隔离——而 composer 是唯一能守住「依赖隔离」这条底线的工具。
为什么在 composer.json 里 require 另一个服务就等于埋雷
常见错误现象：composer require pizzup/order-service 后，user-service 能直接 new OrderService()、调用其私有方法、甚至读写它的数据库迁移文件。
这不是复用，是紧耦合绑架。一旦 order-service 升级 PHP 版本、改命名空间、删掉某个 DTO 类，user-service 的 composer install 就会失败，CI 直接中断。
根本原因在于：Composer 的 require 指令会把目标包的全部代码（含 src/、tests/、migrations/）拉进当前 vendor 目录，并纳入自动加载范围——它不区分「接口」和「实现」。
正确做法是：
- 所有跨服务调用必须走明确定义的契约：HTTP 接口（OpenAPI spec）、消息事件（schema registry）、或共享 DTO 包（见下条）
- 绝不允许在 A 服务的
composer.json中requireB 服务的主代码包 - 若需复用逻辑，抽成独立的私有包，例如
pizzup/dto-order，仅含OrderCreatedEvent等不可变结构 - 该 DTO 包的
autoload必须严格限定命名空间，如"Pizzup\Dto\Order\": "src/Order/"，禁止映射到根目录或全局命名空间
如何用 repositories + version constraint 控制领域边界
私有包不是万能的。当 pizzup/user-dto 发布了 v2.0 并修改了 UserProfile 字段，而 pizzup/notification-service 还卡在 v1.3，就会出现反序列化失败或字段丢失。
这时不能靠“大家自觉升级”，而要靠 Composer 的版本约束机制强制收敛：
- 在 notification-service 的
composer.json中写"pizzup/user-dto": "^1.3"，而非"^1.0"或"dev-main" - 私有 Git 仓库必须打语义化标签（
v1.3.0），不能只推分支 - CI 流程中加入检查：
composer show pizzup/user-dto --format=json | jq '.version'必须匹配预期值 - DTO 包自身应禁用
autoload-dev，避免测试类被意外加载进生产环境
性能影响：私有 VCS 仓库会略微拖慢 composer update（因需 clone 元数据），但 composer install 不受影响——它只读 composer.lock 和缓存。
autoload 的 PSR-4 配置怎么写才不越界
错误配置："App\": "src/" 看似简洁，实则危险。一旦某人把订单逻辑塞进 src/Order/，又没改命名空间，这个类就会被 user-service 自动加载——而它本不该存在于此服务中。
正确做法是让 autoload 成为边界守门员：
- 每个服务的
composer.json中autoload只映射自己明确拥有的命名空间："Pizzup\UserService\": "src/" - 禁止使用通配符或宽泛前缀，如
"Pizzup\"或"App\" - DTO 包的 autoload 必须与包名完全一致：
"Pizzup\Dto\User\": "src/User/"，且该包不声明任何其他命名空间 - 执行
composer dump-autoload --optimize后检查vendor/composer/autoload_psr4.php，确认无冗余映射
容易踩的坑：本地开发时用 composer dump-autoload -a（classmap 模式）绕过 PSR-4 检查，导致上线后类找不到——这说明 autoload 配置本身就有缺陷，不是环境问题。
CI/CD 中 composer install 的执行时机很关键
典型错误：在 CI 流水线最开始就全局运行 composer install，然后才 checkout user-service 子目录。结果是整个单体仓库的 vendor 被装满，包含所有服务的依赖，镜像体积暴涨、启动变慢、安全扫描告警翻倍。
真正松散的落地点，在于构建粒度：
- 每个服务的 CI job 必须
cd进入自身目录后再执行composer install --no-dev --optimize-autoloader - Dockerfile 中
COPY . /app前，先git submodule update --init或git sparse-checkout，确保只拉取当前服务代码 - 禁止在根目录放
composer.json，哪怕只是用来做“统一管理”——那是单体架构的幻觉 - 如果用了私有包，CI runner 必须预配置好
auth.json，否则composer install会在私有仓库认证环节卡住，超时失败
最常被忽略的一点：不同服务可能依赖冲突的扩展（比如一个要 ext-amqp，另一个要 ext-redis），它们必须构建在各自定制的 PHP 基础镜像上——composer 管不了扩展，但它会第一个暴露这个问题。
