.NET 6极简API中如何正确处理CORS预检OPTIONS请求？

在.NET 6+的极简API中，无需手动映射OPTIONS请求，官方推荐使用内置的CORS中间件来处理，这不仅能自动处理预检OPTIONS请求，还能正确配置CORS响应头，同时避免破坏Swagger的正常运行。

具体步骤： #

1. 注册CORS服务
   在Program.cs中，先通过AddCors注册CORS策略，可根据需求配置允许的源、HTTP方法和请求头：

builder.Services.AddCors(options =>
{
    options.AddPolicy("CustomCorsPolicy", policy =>
    {
        // 示例：允许指定前端域名跨域，允许所有方法和头
        policy.WithOrigins("https://your-frontend-app.com")
              .AllowAnyMethod()
              .AllowAnyHeader();
        
        // 如果是测试环境，可使用宽松配置（生产环境不建议）：
        // policy.AllowAnyOrigin()
        //       .AllowAnyMethod()
        //       .AllowAnyHeader();
    });
});

2. 启用CORS中间件
   注意中间件的顺序，必须放在路由映射（MapGet/MapPost等）之前，且在Swagger中间件之后（如果使用Swagger）：

app.UseSwagger();
app.UseSwaggerUI();

// 启用CORS，应用上面定义的策略
app.UseCors("CustomCorsPolicy");

// 映射你的极简API路由
app.MapGet("/HelloWorld", () => "Hello World!");

app.Run();

为什么手动映射OPTIONS会出问题？ #

你之前尝试用MapMethods手动返回200的方式，会覆盖CORS中间件对预检请求的自动处理逻辑，同时干扰Swagger的接口元数据生成，导致Swagger无法正常识别接口的完整信息，进而出现异常。

对比.NET Framework的旧做法 #

在.NET Framework 4.7中手动在Application_AuthenticateRequest终止OPTIONS请求的方式，是因为当时没有专门的CORS中间件支持。而.NET 6+已经提供了成熟的CORS中间件，完全替代了这种手动处理的方式，无需再通过终止请求来处理预检。

如果确实有特殊场景需要自定义OPTIONS请求的处理逻辑，建议在CORS中间件的基础上扩展，而非直接手动映射OPTIONS路由，避免出现兼容性问题。

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