Azure孤立模型函数中配置Flurl依赖注入式Delegating Handler

问题根源 #

你当前的DI写法失效，核心原因有两点：

1. 生命周期不匹配：FlurlClientCache是单例服务，而你注册的MyDelegationHandler是Transient。直接在单例工厂里调用sp.GetService<MyDelegationHandler>()会导致Handler被固定为单例实例，无法随请求创建新实例，同时如果ICorrelationIdQuery是请求级别的依赖，会引发生命周期冲突。
2. 作用域错误：在单例服务的初始化逻辑中直接使用根服务提供者获取Transient/Scoped依赖，无法拿到当前请求作用域内的服务实例，不符合Azure函数孤立模型的DI生命周期规则。

正确实现方案 #

步骤1：注册所有依赖 #

先确保基础依赖的生命周期配置正确：

// 注册CorrelationId查询服务（根据你的实际实现类调整）
services.AddScoped<ICorrelationIdQuery, CorrelationIdQuery>();
// 注册自定义Delegating Handler为Scoped（匹配请求生命周期）
services.AddScoped<MyDelegationHandler>();

步骤2：正确配置FlurlClientCache #

通过创建请求作用域来获取当前请求的Handler实例，避免单例捕获问题：

services.AddSingleton<IFlurlClientCache>(sp => 
{
    var clientCache = new FlurlClientCache();
    clientCache.WithDefaults(builder => 
    {
        builder.AddMiddleware(() => 
        {
            // 创建当前请求的作用域，获取Scoped级别的Handler实例
            using var scope = sp.CreateScope();
            return scope.ServiceProvider.GetRequiredService<MyDelegationHandler>();
        });
    });
    return clientCache;
});

关键说明 #

• 使用CreateScope()获取当前请求的服务提供者，确保每次Flurl发起请求时，都能拿到对应作用域内的MyDelegationHandler和ICorrelationIdQuery实例，符合DI最佳实践。
• 避免提前调用BuildServiceProvider()，这会破坏DI容器的初始化流程，导致服务实例不一致。

内容的提问来源于stack exchange，提问作者Bobby Jose