guzzle 的 client 实例不继承 handler 中的配置（如 base_uri、verify 等），handler 仅负责执行请求；中间件无法自动共享 client 配置，需显式传递或通过依赖注入统一管理。
guzzle 的 client 实例不继承 handler 中的配置（如 base_uri、verify 等），handler 仅负责执行请求；中间件无法自动共享 client 配置，需显式传递或通过依赖注入统一管理。
在 Guzzle 7+ 中，Client、HandlerStack 和 Middleware 各司其职，彼此解耦：
- Client 是高层抽象：负责构建请求（合并 base_uri、headers、query 等选项）、序列化参数、触发中间件链，并最终将标准化后的 RequestInterface 交由 handler 执行；
- HandlerStack 是执行管道：它本身不存储配置，仅按顺序调用注册的中间件；底层默认使用 CurlHandler（或自定义 handler）真正发起网络请求；
- Middleware 是无状态拦截器：它接收 callable $handler（即下一环节的执行函数），可修改请求/响应，但不会自动获取或继承外部 Client 的配置项（如 base_uri 或 verify）。你传入 AccessTokenGuzzleMiddleware 的 $client 是一个独立实例，其配置与主 Client 完全无关。
因此，你最初提出的简化写法：
$middleware = new AccessTokenGuzzleMiddleware(
client: new Client([
'headers' => [...],
'base_uri' => config('spica.url') . config('spica.space_api.path'),
'verify' => config('spica.verify_ssl'),
]),
// ...
);
$spaceClient = new Client(['handler' => $stack]); // ❌ 缺少 base_uri / verify / headers会导致运行时错误：$spaceClient 发起请求时，因未声明 base_uri，会抛出 GuzzleHttp\Exception\InvalidArgumentException: URI must be a string or UriInterface；同理，缺失 verify 可能导致 SSL 验证失败（取决于环境默认值）。
✅ 正确做法是分离关注点 + 精准注入：
- 为中间件所需的内部 Client 单独配置（如用于获取 Token 的认证客户端），只需最小必要选项（如 verify）；
- 为主业务 Client 显式声明全部运行时必需配置（base_uri、headers、verify），不可省略；
- 避免重复硬编码：利用 Laravel 服务容器实现配置复用。
推荐方案（Laravel 9+）：
// 在 AppServiceProvider@register() 中
use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;
$this->app->when(AccessTokenGuzzleMiddleware::class)
->needs(Client::class)
->give(function () {
// 仅用于内网 Token 获取，无需 base_uri（因 tokenUrl 已含完整 URL）
return new Client(['verify' => config('spica.verify_ssl')]);
});
$this->app->singleton('spica.space_client', function (Application $app) {
$stack = HandlerStack::create();
$stack->push(new AccessTokenGuzzleMiddleware(
client: $app->make(Client::class), // 注入上述专用 client
cache: $app->make('cache')->store(),
tokenUrl: config('spica.url') . 'auth',
clientId: config('spica.space_api.client_id'),
clientSecret: config('spica.space_api.key')
));
return new Client([
'base_uri' => config('spica.url') . config('spica.space_api.path'),
'headers' => [
'Content-Type' => 'application/json',
'Accept' => 'application/json',
],
'verify' => config('spica.verify_ssl'),
'handler' => $stack,
]);
});然后在 Service 中直接依赖注入：
class SpicaService
{
public function __construct(
private Client $spaceClient // ← 自动解析为预配置的 'spica.space_client'
) {}
}⚠️ 注意事项：
- 不要试图让 middleware “读取” 主 Client 的配置——Guzzle 没有此类机制；
- HandlerStack 中的中间件顺序很重要：越早 push 的越靠近请求发起端（如日志中间件宜放在最外层，鉴权中间件紧邻 handler）；
- 若需动态修改主 Client 行为（如切换租户 header），应使用 on_stats 或自定义 middleware，而非复用配置。
总结：Guzzle 的配置作用域严格限定于每个 Client 实例。复用的关键在于 依赖注入容器的精准绑定，而非期望 handler 或 middleware 自动继承父级配置。
