建议MassTransit提供以IServiceProvider为载荷的容器无关范围提供程序

Great question—this behavior is actually an intentional design choice in MassTransit's container integrations, and it's there to solve some key lifecycle and flexibility problems when handling messages. Let me break it down for you:

Why Does MassTransit Add Container-Specific Scopes to ConsumeContext? #

• Lifetime Boundary Alignment: Every message consumed by MassTransit gets its own dedicated container scope (like Autofac's ILifetimeScope or MS DI's IServiceScope). This scope is tied directly to the lifespan of the message consumption. By stuffing it into ConsumeContext's payload, MassTransit ensures any component (consumer, filter, middleware) that needs to resolve services can grab a scope that's guaranteed to be scoped to the current message—no cross-contamination between different message processing instances.
• Flexibility for Edge Cases: Sometimes constructor injection isn't enough. For example, if you need to dynamically resolve a service based on content in the message, having direct access to the current scope lets you do that without jumping through hoops.
• Leverage Container-Native Features: Different containers have unique perks—Autofac's lifetime scope tags, MS DI's scope validation, etc. Exposing the raw scope object lets you tap into these features when you need them, instead of being limited to a generic abstraction.

How to Work With These Scopes #

If you need to use the scope in your consumer or middleware, it's straightforward to fetch via ConsumeContext's GetPayload<T>() method:

// Example with Autofac
var lifetimeScope = context.GetPayload<ILifetimeScope>();
var scopedService = lifetimeScope.Resolve<IMyScopedService>();

// Example with Microsoft.Extensions.DependencyInjection
var serviceScope = context.GetPayload<IServiceScope>();
var scopedService = serviceScope.ServiceProvider.GetRequiredService<IMyScopedService>();

Can You Avoid Exposing Container-Specific Types? #

You technically can disable adding these payloads, but it's not recommended—MassTransit's internal logic (like creating consumer instances) relies on these scope objects to manage lifecycle correctly. A better approach to keep your consumer code container-agnostic is:

• Wrap the Container Scope in a Generic Abstraction: Create a simple interface that abstracts service resolution, then implement it for your container. This way your consumers depend on a generic interface instead of container-specific types. For example:

public interface IScopedServiceResolver
{
    T Resolve<T>();
}

// Autofac implementation
public class AutofacScopedServiceResolver : IScopedServiceResolver
{
    private readonly ILifetimeScope _lifetimeScope;

    public AutofacScopedServiceResolver(ILifetimeScope lifetimeScope)
    {
        _lifetimeScope = lifetimeScope;
    }

    public T Resolve<T>() => _lifetimeScope.Resolve<T>();
}

Register this interface with your container, and inject IScopedServiceResolver into your consumers instead of directly accessing the container scope. This keeps your consumer code clean and decoupled from specific container implementations.

If you really need to roll your own scope handling, you could implement a custom IConsumerScopeProvider that doesn't add the container-specific payload—but be warned, this requires deep knowledge of MassTransit's container integration and could break internal functionality if done incorrectly.

内容的提问来源于stack exchange，提问作者Johnny 5