应将 openapi 生成的 php 客户端抽为独立 composer 包，统一发布至私有仓库；各微服务通过版本约束引用，避免重复生成、版本不一致及构建污染。
用 openapi-generator-cli 生成 PHP 客户端时，如何让所有微服务共用同一套依赖管理？
核心是别让每个服务都跑一遍 openapi-generator-cli generate 并各自写 composer.json —— 这会导致版本不一致、重复维护、升级踩坑。正确做法是把客户端代码和它的 composer.json 抽成独立包，统一发布到私有 Packagist 或 Git 仓库。
实操建议：
- 用
openapi-generator-cli生成客户端时，加--additional-properties=packageVersion=1.2.0,packageName=acme-service-user，确保包名和版本可控 - 生成后删掉
vendor/和composer.lock，只保留源码 + 自己写的composer.json（含"require": {"php": "^8.1"}等最小依赖） - 在该目录下运行
composer publish（需配置私有 repo）或打 Git tag，例如v1.2.0 - 各微服务的
composer.json中直接引用："acme/service-user-client": "^1.2"
为什么不能直接在项目里 require openapitools/openapi-generator-cli 并自动生成？
因为 openapi-generator-cli 是构建期工具，不是运行时依赖；把它塞进 require 会导致所有服务都带上 Node.js 依赖、体积膨胀、CI 构建变慢，还容易因 CLI 版本不一致导致生成代码差异。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 本地生成的客户端类，在测试环境报
Class not found—— 实际是 autoloader 没扫到动态生成的目录 - CI 流水线里
composer install后立刻调用openapi-generator-cli，但没装 Node.js 或权限不足，直接失败 - 不同开发者用的 CLI 版本不同（
7.2vs7.6），生成的ApiClient.php方法签名不一致
composer.json 中怎么约束客户端包的 PHP 版本和扩展？
客户端包自己的 composer.json 必须显式声明运行时要求，否则上层服务可能装了却跑不起来。比如它用了 ext-curl 发请求、ext-json 解析响应，这些都不能靠“应该有”来假设。
关键参数差异：
-
"require": { "php": "^8.1", "ext-curl": "*", "ext-json": "*" }—— 强制检查，安装失败比运行时报错更早暴露问题 - 不要写
"require-dev"里放guzzlehttp/guzzle—— 它是运行时核心依赖，不是开发用的 - 如果客户端内部用了
psr/http-client接口，要明确 require 具体实现，比如"guzzlehttp/guzzle": "^7.8"，避免运行时无适配器
生成的客户端如何支持多环境 Base URL 和认证？
硬编码 https://user.svc.cluster.local 在 ApiClient 构造函数里，等于把部署细节写死进 SDK —— 微服务换 namespace 或迁到新集群就得改包、发版、全量更新，不可接受。
实操建议：
- 生成时加
--additional-properties=withInterfaces=true，得到UserApiInterface，方便运行时注入不同实现 - 客户端包提供一个工厂类，比如
Acme\Service\User\ClientFactory::create(array $config)，从$config['base_uri']和$config['bearer_token']构建实例 - 各服务通过自己的 DI 容器传入配置，而不是让客户端自己读
$_ENV或.env—— 避免耦合和测试困难
最容易被忽略的是：生成的客户端默认不校验 TLS，verify=false 开关藏在 Guzzle 配置里，而这个配置往往被包作者忽略，上线后遇到证书错误才去翻源码。
