微服务依赖隔离靠 Composer 实现，需严格分层 require/require-dev、独立管理 composer.lock、收敛 autoload 到服务边界、使用私有仓库与语义化版本，并辅以契约测试兜底。
微服务不是靠拆包实现的，而是靠依赖隔离实现的；Composer 本身不支持“微服务”，但它的依赖解析、版本锁定和 autoload 隔离能力，是 PHP 微服务落地最现实的基础设施。
composer.json 的 require 和 require-dev 必须严格分层
在微服务场景下，每个服务都是独立部署单元，require 和 require-dev 不只是开发习惯问题，而是运行时边界问题。
- 所有运行时必需的包（如
guzzlehttp/guzzle、slim/slim、ext-pdo_pgsql）必须进require，否则上线后Class not found或Extension not loaded直接报错 -
require-dev只能放纯本地工具：比如phpunit/phpunit、phpstan/phpstan、symfony/maker-bundle—— 它们不该出现在生产镜像里 - 特别注意
symfony/flex：它不参与运行，但会修改配置文件，应始终放在require-dev；否则 CI 中 recipe 自动注入可能污染生产环境 - 漏掉
--no-dev是高频翻车点：Docker 构建时若没加该参数，debug-bundle可能被加载，/_profiler 暴露堆栈和环境变量
composer.lock 文件必须提交且按服务粒度管理
单体项目共用一个 composer.lock 没问题，但微服务架构中，每个服务应有自己独立的 composer.lock，且必须提交到对应仓库主分支。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不同服务对同一包（如
monolog/monolog）的版本需求可能冲突：服务 A 要 ^2.0，服务 B 已升级到 ^3.0；共享 lock 文件会导致安装失败或隐性降级 - CI 流程中必须用
composer install --no-interaction --optimize-autoloader --no-dev，不能用update—— 后者会重写 lock，破坏可重现性 - 私有包（如
acme/shared-utils）引用 dev 分支时，必须带别名：composer require acme/shared-utils:dev-main as 1.0.x-dev，否则 Composer 解析失败并报Could not find package - 定期人工检查
composer show --tree输出，确认间接依赖没引入意外的高危组件（如含已知 CVE 的旧版ramsey/uuid）
autoload 配置要收敛到服务边界，禁止跨服务命名空间映射
PSR-4 映射不是越宽越好；微服务要求类加载路径与服务职责强绑定，否则自动加载器会“越界”加载其他服务代码，破坏隔离性。
- 每个服务的
composer.json中autoload应只映射自身命名空间，例如："App\": "src/"，绝不写成"Acme\": "vendor/acme/*/src" - 共享库（如认证工具包）应发布为独立 Composer 包，通过
require引入，而非用 autoload 把别人 src 目录拖进自己加载范围 - 若需覆盖某些类（如测试 Mock），应使用
autoload-dev单独配置，且仅限测试入口生效，避免污染主加载器 - 执行
composer dump-autoload --optimize后，检查vendor/composer/autoload_psr4.php是否混入了非本服务的映射条目
私有仓库 + 版本别名是跨服务协作的最小可行方案
没有私有 Packagist，微服务之间的依赖就只能靠 path 仓库或 git submodules，这两种方式在 CI/CD 中极难维护。
- 用 Satis 或 Private Packagist 搭建私有仓库，把每个微服务打包为
acme/user-service、acme/order-service等标准包名 - 内部包必须用语义化版本发布（
1.2.3），禁止长期停留在dev-main；CI 流程应在 tag 推送后自动构建并发布到私有源 - 下游服务引用时，用
^1.2而非dev-main，否则无法享受 Composer 的 SAT 依赖解析能力，容易因分支漂移导致构建失败 - 若必须临时调试某分支，可用
composer require acme/shared-utils:dev-feature/login-flow --prefer-source，但上线前必须切回稳定版本约束
最易被忽略的一点：Composer 的依赖解析是静态的，它不感知服务间 HTTP 或消息调用的契约变化。当你升级了 acme/payment-client 到 v2，但没同步更新 acme/order-service 的调用逻辑，运行时 500 错误不会在 composer install 阶段暴露——这需要接口契约文档 + 兼容性测试兜底，而不是依赖管理本身能解决的。
