ASP.NET Core 运行时如何修改配置以适配带自定义请求头的测试场景

你之前的方案不生效核心原因是直接修改全局配置或者依赖全局配置的IOptions系列接口，既会有并发冲突风险，也无法做到请求级别的配置隔离，完全不需要读写本地appsettings文件，推荐用请求作用域配置隔离方案，实现成本极低且无副作用：

核心思路 #

不修改全局IConfiguration实例，针对检测到的测试请求，单独注入作用域级别的mock配置，普通请求仍然使用全局默认配置，两类请求的配置完全隔离互不影响。

具体实现步骤 #

1. 定义强类型配置类 #

把你需要替换的URL配置封装为强类型类，方便绑定和注入：

// 示例：你要替换的第三方API地址配置
public class ApiServiceSettings
{
    public string UserServiceUrl { get; set; }
    public string OrderServiceUrl { get; set; }
}

2. 编写请求配置中间件 #

在请求管道最前端加入中间件，检测自定义测试请求头，为不同请求注入对应的配置：

public class MockConfigMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ApiServiceSettings _globalSettings;
    // 预加载mock配置，开启reloadOnChange支持mock文件热更新，无需重启应用
    private static readonly Lazy<ApiServiceSettings> _mockSettings = new(() => 
        new ConfigurationBuilder()
            .AddJsonFile("appsettings.mock.json", optional: false, reloadOnChange: true)
            .Build()
            .GetSection(nameof(ApiServiceSettings))
            .Get<ApiServiceSettings>()
    );

    public MockConfigMiddleware(RequestDelegate next, IConfiguration globalConfig)
    {
        _next = next;
        _globalSettings = globalConfig.GetSection(nameof(ApiServiceSettings)).Get<ApiServiceSettings>();
    }

    public async Task InvokeAsync(HttpContext context)
    {
        const string testHeaderKey = "X-Acceptance-Test";
        // 检测是否是验收测试/冒烟测试请求
        if (context.Request.Headers.TryGetValue(testHeaderKey, out var val) 
            && string.Equals(val, "Enable", StringComparison.OrdinalIgnoreCase))
        {
            // 测试请求注入mock配置
            context.Features.Set(_mockSettings.Value);
        }
        else
        {
            // 普通请求注入全局默认配置
            context.Features.Set(_globalSettings);
        }
        await _next(context);
    }
}

3. 注册中间件和依赖服务 #

在Program.cs中注册相关服务和中间件：

var builder = WebApplication.CreateBuilder(args);
// 注册HttpContext访问器
builder.Services.AddHttpContextAccessor();

// 如果你不想修改原有代码的注入逻辑，可直接替换IOptions的实现
builder.Services.AddScoped<IOptions<ApiServiceSettings>>(sp => 
{
    var accessor = sp.GetRequiredService<IHttpContextAccessor>();
    return Options.Create(accessor.HttpContext.Features.Get<ApiServiceSettings>());
});

var app = builder.Build();
// 中间件要放在路由、认证等其他中间件之前注册
app.UseMiddleware<MockConfigMiddleware>();

// 其他中间件注册...
app.Run();

4. 业务代码直接使用配置 #

原有业务代码不需要修改，只要是注入IOptions<ApiServiceSettings>的地方会自动适配当前请求的配置：

public class OrderController : ControllerBase
{
    private readonly ApiServiceSettings _settings;

    public OrderController(IOptions<ApiServiceSettings> settings)
    {
        _settings = settings.Value;
    }

    [HttpGet]
    public async Task<IActionResult> GetList()
    {
        // 测试请求拿到的是mock地址，普通请求拿到的是默认配置地址
        var data = await HttpClient.GetFromJsonAsync($"{_settings.OrderServiceUrl}/api/orders");
        return Ok(data);
    }
}

方案优势 #

• 无并发风险：请求级配置隔离，测试请求的配置完全不会影响普通用户请求
• 实现简单：不需要读写本地配置文件，不需要修改全局配置，mock配置可以单独管理支持热更新
• 无侵入性：原有业务代码几乎不需要修改，适配现有IOptions注入逻辑
• 扩展性强：如果需要支持动态mock参数，可直接从请求头/请求参数读取配置，不需要依赖本地JSON文件

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