cors不生效主因是中间件顺序错误：usecors必须紧接userouting之后、useauthorization和mapcontrollers之前；allowcredentials为true时withorigins不可用"*"；自定义请求头需显式声明withheaders，响应头需withexposedheaders。
AddCors 不生效？八成是中间件顺序错了，不是代码写得不对。
UseCors 必须紧挨着 UseRouting 放
ASP.NET Core 的 CORS 中间件对执行顺序极其敏感。它必须在 UseRouting 之后、UseAuthorization 和 UseEndpoints（或 MapControllers）之前——而且最好紧挨着 UseRouting，别插在 UseAuthentication 后面或 UseHttpsRedirection 中间。
-
UseHttpsRedirection可以放在UseCors前，但不能挡在UseRouting和UseCors之间 - 开发时启用了
UseDeveloperExceptionPage()，也要确保它不打断中间件链；否则 OPTIONS 预检请求根本进不到 CORS 管道里 - .NET 6+ Minimal Hosting 模式下，
builder.Services.AddCors和app.UseCors是分离的两步，漏掉任意一个都会失效
AllowCredentials = true 时，AllowOrigins 不能用 "*"
前端如果设置了 credentials: true（比如带 Cookie 或 Authorization header），浏览器会强制要求后端响应头 Access-Control-Allow-Origin 必须是具体源，而不能是通配符 *。否则控制台直接报错：
Failed to load http://api.example.com/data: The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when the request's credentials mode is 'include'.
- 必须显式列出可信源：
policy.WithOrigins("https://example.com", "http://localhost:3000") -
http://localhost:3000和http://127.0.0.1:3000是两个不同源，都得写全 - 协议、端口、大小写全部要严格匹配；不要拼接字符串构造 origin
- 真需要动态 origin（如 SaaS 多租户），得实现
ICorsPolicyProvider，但绕过校验会引入安全风险，慎用
POST 被拦？检查 WithHeaders 和 WithExposedHeaders
OPTIONS 预检通过了，但后续 POST 请求仍被拦截，大概率是服务端没声明允许的请求头或没暴露响应头。
- 前端发了
Content-Type: application/json，后端就得WithHeaders("Content-Type")；如果发了X-Requested-With，也得显式加进去 - 只要请求头不是简单头（
Accept、Content-Type、Cache-Control等），就会触发预检；application/json属于“简单值”但某些浏览器仍可能触发，建议统一显式允许 - 前端 JS 想读取响应里的
X-Total-Count或X-RateLimit-Remaining这类自定义 header，后端必须提前调用WithExposedHeaders("X-Total-Count", "X-RateLimit-Remaining")
最常被忽略的点：CORS 配置不是“写了就完事”，而是和中间件顺序、凭据开关、头声明三者强绑定。少一个条件，浏览器就拦一个请求——而且往往只拦 POST/PUT/DELETE，GET 却能通，让人误以为问题已解决。
