Actix中间件Transform trait实现中泛型S与B的传入方式疑问

核心逻辑：Rust的泛型impl自动推导 #

你这个疑问的关键是Rust对泛型impl的类型推导机制，S和B不需要手动传入，而是由Rust编译器在使用SayHi作为中间件时，自动根据上下文推导出来的。

1. impl<S, B> Transform<...> for SayHi的本质 #

这个写法是给无泛型的结构体SayHi实现了一个泛型版本的Transform trait。意思是：只要存在满足where约束的类型S和B，SayHi就自动拥有对应Transform的实现。

2. 类型推导的触发时机 #

当你在Actix中把SayHi作为中间件添加到服务链时（比如用.wrap(SayHi)），Actix的内部逻辑会调用Transform trait的new_transform方法。此时：

• 编译器会根据被包裹的下一层服务的类型自动推断出S（即下一个服务的具体类型）
• 再通过S实现的Service trait关联类型Response = ServiceResponse<B>，进一步推断出B（响应体的具体类型）

3. 关于new_transform的可见性问题 #

你感觉的“矛盾”其实不存在：

• 当你调用.wrap(SayHi)时，编译器已经先确认了下一层服务S满足where子句的约束（S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error>等），所以SayHi对应的Transform实现是可见的，new_transform方法自然就能被调用。
• new_transform的参数service: S就是编译器推断S类型的直接依据，完全不需要手动指定泛型参数。

实际场景示例 #

假设你有一个处理请求的基础服务，类型是MyService，它的响应体是Json<MyResponse>（对应B = Json<MyResponse>）。当你编写如下代码：

App::new()
    .wrap(SayHi)
    .service(my_service);

编译器会自动完成以下推导：

• S = MyService
• B = Json<MyResponse>
  然后自动匹配到对应的Transform实现，调用new_transform生成SayHiMiddleware<MyService>实例，将其插入到服务调用链中。

内容的提问来源于stack exchange，提问作者Luke Puplett