C#跨域核心是后端配置Access-Control-Allow-Origin等响应头，ASP.NET Core需在Program.cs中三步完成：AddCors注册策略、UseCors启用且位置在UseAuthorization前、策略中禁用AllowAnyOrigin与AllowCredentials组合；Web API 2则依赖EnableCorsAttribute全局或控制器级配置。
直接说结论：C# 处理跨域问题，核心是让服务器在响应头中正确返回 Access-Control-Allow-Origin 等 CORS 相关字段——但**不能靠前端“改请求”解决，必须后端主动配置**；不同 C# 框架（.NET Framework Web API vs ASP.NET Core）配置方式完全不同，混用会导致 403 或预检失败。
ASP.NET Core 项目：在 Program.cs 中配策略 + 中间件
这是当前主流方案（.NET 6+），必须三步全做，缺一不可：
-
builder.Services.AddCors()：注册服务并定义命名策略（比如叫"AllowFrontend"） - 策略里明确指定源（
.WithOrigins("http://localhost:5173")），禁止用.AllowAnyOrigin()配合.AllowCredentials()（会直接报错） -
app.UseCors("AllowFrontend")：必须放在app.UseAuthorization()之前，否则不生效
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddCors(options =>
{
options.AddPolicy("AllowFrontend", policy =>
{
policy.WithOrigins("http://localhost:5173", "https://prod.myapp.com")
.AllowAnyHeader()
.AllowAnyMethod()
.AllowCredentials(); // 若需带 cookie/token，必须指定具体源，不能用 "*"
});
});
builder.Services.AddControllers();
var app = builder.Build();
app.UseCors("AllowFrontend"); // ⚠️ 位置很关键：必须在 UseAuthorization 之前
app.UseAuthorization();
app.MapControllers();
app.Run();
Web API 2（.NET Framework）：用 Microsoft.AspNet.WebApi.Cors 包
老项目常见，依赖 NuGet 包，且配置入口在 Global.asax.cs 或 WebApiConfig.cs：
- 先安装包：
Install-Package Microsoft.AspNet.WebApi.Cors - 全局启用：在
GlobalConfiguration.Configuration.EnableCors()中传入EnableCorsAttribute - 注意通配符风险：
new EnableCorsAttribute("*", "*", "*")在生产环境等同于裸奔，尤其带认证时会失效 - 更安全的做法是控制器粒度控制：
[EnableCors(origins: "http://localhost:3000", headers: "*", methods: "*")]
// WebApiConfig.cs
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
var cors = new EnableCorsAttribute(
origins: "http://localhost:3000",
headers: "Content-Type,Authorization,X-Requested-With",
methods: "GET,POST,PUT,DELETE,OPTIONS");
config.EnableCors(cors);
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}}
遇到 OPTIONS 预检失败？检查这三点
浏览器对非简单请求（如带 Authorization 头、Content-Type: application/json）会先发 OPTIONS 请求。失败通常因为：
- CORS 中间件没覆盖到
OPTIONS路由（ASP.NET Core 中UseCors必须在UseRouting之后、UseEndpoints之前） - 策略中没显式允许
OPTIONS方法（.WithMethods("GET", "POST", "OPTIONS")） - IIS 或反向代理（如 Nginx）截断了响应头，或自己写了
web.config但Access-Control-Allow-Methods值里漏了OPTIONS
别踩这些坑
很多问题不是 CORS 配错了，而是被其他机制干扰：
-
AllowCredentials = true时，WithOrigins不能写"*"，否则浏览器直接拒绝——必须列明具体协议+域名+端口 - 前端用
fetch发送带凭据的请求，必须加credentials: "include"，否则后端收不到 cookie - IIS 部署时，若用
web.config手动加响应头，要确认 - 本地开发用 Vue/React 的
devServer.proxy是临时绕过 CORS 的前端方案，上线必须切回真实 CORS 配置
最常被忽略的一点：CORS 是浏览器强制执行的安全策略，Postman、curl、后端调用完全不受影响——所以测试一定要用真实页面打开，看浏览器开发者工具 Network 标签页里的请求头和响应头是否完整出现 Access-Control-Allow-* 字段。
