ASP.NET(.NET8)中ServiceCollection与WebApplication配置CORS的差异及原因

ASP.NET（.NET 8）官方文档指出，启用CORS应通过WebApplicationBuilder的ServiceCollection添加策略，再用WebApplication启用CORS，示例代码如下：

var builder = WebApplication.CreateBuilder(args);

// ...

builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(
        policy =>
        {
            policy.WithOrigins("http://example.com");
        });
});

var application = builder.Build();

application.UseCors();

但WebApplication的UseCors有接受策略构建器的重载，可直接配置：

var builder = WebApplication.CreateBuilder(args);

// ...

var application = builder.Build();

application.UseCors(
        policy =>
        {
            policy.WithOrigins("http://example.com");
        });

本地测试两种方案效果一致，为何文档建议在ServiceCollection中定义CORS？

虽然两种写法在简单场景下效果相同，但文档推荐通过ServiceCollection定义CORS策略，主要有以下几个原因：

• 策略复用：如果应用需要在多个地方（比如不同中间件分支、控制器/Action上通过[EnableCors]特性）使用同一套CORS规则，提前在服务容器中定义命名策略或默认策略，就能直接复用，不用重复编写相同配置逻辑。
• 与其他框架组件兼容：SignalR、gRPC等ASP.NET组件处理跨域请求时，依赖服务容器中注册的CORS策略，内联配置的策略无法被这些组件识别调用。
• 启动逻辑更清晰：将CORS策略配置放在服务注册阶段，能实现服务配置与中间件管道的逻辑分离，符合ASP.NET的设计规范，便于后续维护和扩展。
• 支持复杂配置场景：通过AddCors可以注册多个命名策略，针对不同业务场景使用不同规则；还能结合appsettings.json等配置文件动态加载策略参数，这些功能是内联UseCors配置无法实现的。

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