Service类不适合初始化第三方SDK，因其默认按需实例化，易导致连接泄漏、证书冲突或配置错乱；应改用容器服务提供者（TP6+）或公共启动文件（TP5.x）统一单例初始化。
不适合直接在 Service 类里做第三方 SDK 初始化——除非你明确控制了初始化时机、作用域和复用逻辑，否则极易引发连接泄漏、配置错乱或并发异常。
为什么 Service 类不是初始化 SDK 的安全位置
ThinkPHP 的 Service（如 app/service/AlipayService.php）默认是“按需实例化”的普通类，每次 new 或容器解析都会新建对象。而多数第三方 SDK（如支付宝 AopClient、微信 WechatPay\Client）内部维护连接池、证书句柄或全局配置状态，重复初始化会导致：
- HTTP 连接未复用，频繁握手拖慢响应
- 证书文件被多次加载，可能触发 OpenSSL 资源冲突
- SDK 内部单例（如 Guzzle 实例）被覆盖，日志/中间件丢失
- 配置从
config('pay')动态读取时，若环境未就绪（如命令行场景），会读到空值
推荐初始化位置：容器服务提供者（TP6+）或公共启动文件（TP5.x）
真正可控的初始化入口必须满足两个条件：只执行一次、在框架完全就绪后运行。
- TP6.x 项目：在
app/provider.php中注册服务提供者，用$this->app->bind()绑定单例，例如：$this->app->bind('alipay.client', function ($app) { return \AlibabaCloud\Client\AlibabaCloud::accessKeyClient() ->regionId('cn-hangzhou') ->asGlobalClient(); }); - TP5.1–5.2：在
public/index.php中 TP 初始化之后、请求分发之前，手动调用一次初始化函数并存入静态变量或think\Container - 绝对不要在 Service 构造函数里写
new AopClient()或AlibabaCloud::accessKeyClient()—— 这等于把“连接建立”塞进了业务逻辑链路
Service 类该做什么：封装调用，不管理生命周期
Service 的职责是定义清晰的接口契约，把 SDK 调用包装成可测试、可替换的方法，例如：
立即学习“PHP免费学习笔记（深入）”；
-
sendSms($phone, $template, $params)：内部从容器获取已初始化好的客户端 -
verifyNotify($rawBody)：只处理验签逻辑，不碰file_get_contents('php://input')这类底层操作 - 所有异常统一转为
AppException，不暴露ClientException或ServerException堆栈
如果 SDK 初始化失败（比如证书路径错误），应在服务提供者中抛出异常并中断启动，而不是等到第一次调用 Service 才报错——后者会让问题定位成本翻倍。
容易被忽略的细节：TP6 容器 bind 和 singleton 的区别
用 $app->bind('alipay', AlipayService::class) 每次解析都新建实例；而 $app->singleton('alipay', function() { ... }) 才保证单例。但更关键的是：SDK 客户端本身是否线程/协程安全？微信支付 v3 的 WechatPay\Client 明确要求每个请求使用独立实例（因含签名上下文），这时反而不能全局 singleton，而应由 Service 在方法内按需创建——这个判断点，比“放哪初始化”更重要。
