beego中配置cors须显式指定alloworigins完整列表（如"http://localhost:3000"）、禁用allowallorigins:true与allowcredentials:true共存，且allowheaders需包含"content-type"等实际请求头，否则预检失败或凭据失效。
Beego 的 CORS 配置不难，但错一个参数就卡在预检（preflight）或 401/403/500 响应里——尤其是 AllowCredentials 和 AllowOrigins 同时启用时，Access-Control-Allow-Origin 不能是 "*"，这是硬性限制，不是 Beego 的 bug。
beego.InsertFilter 配置 CORS 中间件的正确写法
别用 AllowAllOrigins: true 搭配 AllowCredentials: true，Go 标准库和浏览器都会拒绝。必须显式列出可信源，且端口、协议、子域名都要对得上。
-
AllowOrigins必须是完整 origin 列表，比如[]string{"http://localhost:3000", "https://app.example.com"}；通配符只支持"http://10.*.*.*"这类 IP 段写法，不支持"https://*.example.com" -
AllowHeaders要包含前端实际发的头，常见漏掉的是"Content-Type"、"X-Requested-With"、"Auth-Token"；大小写不敏感，但值必须完全匹配（如"content-type"也行，但推荐首字母大写） -
ExposeHeaders只在前端 JS 需要读取响应头时才填，比如"X-Total-Count"或自定义分页头；不填不影响数据返回 - 如果用
beego/v2，确保导入的是github.com/beego/beego/v2/server/web/context对应的cors插件，老版本路径不同容易编译失败
OPTIONS 预检请求失败的典型表现与修复
浏览器发了 OPTIONS 请求，但后端没返回 200，或者返回了 200 却没带 CORS 头——这时候前端控制台会报 No 'Access-Control-Allow-Origin' header is present 或 Request header field X-Custom-Header is not allowed。
- 确认路由是否覆盖
OPTIONS：Beego 默认不自动处理 OPTIONS，必须靠cors.Allow()中间件拦截并返回空响应；如果手动写了web.Router("/api/*", &MyController{}, "options:Options")，反而会冲突 - 检查
AllowMethods是否包含实际用到的方法，比如前端用了PATCH，但配置里只有GET,POST,PUT,DELETE，预检就会失败 - 不要在 controller 方法里手动写
ctx.ResponseWriter.Header().Set("Access-Control-Allow-Origin", "...")，中间件已覆盖，重复设置可能被忽略或覆盖不全
带凭证（cookie/session）跨域时的坑
前端设了 credentials: 'include'，后端却没配对，结果 cookie 不发送、session 丢失、登录态失效——这比跨域报错更隐蔽。
-
AllowCredentials: true必须配合AllowOrigins显式列表，且不能含"*"；否则浏览器直接拒绝响应 - 前端发起请求时，
Origin头必须和AllowOrigins中某一项**完全一致**（协议、域名、端口），哪怕只是少个www或端口默认 80/443 没显式写出，都算不匹配 - Beego 默认 session 存在 cookie 里，若跨域请求要带 session，除了 CORS 配置，还要确保
beego.BConfig.WebConfig.Session.SessionOn = true已开启，且SessionProviderConfig支持跨域写入（如 file、redis 都可以，memory 不适合多实例）
最常被忽略的是：开发环境用 http://localhost:3000，生产切到 https://app.example.com，但 AllowOrigins 没同步更新，导致上线后部分用户白屏。建议把允许源抽成配置项，而不是硬编码在 InsertFilter 里。
