生产环境必须用具体域名而非，因会暴露api并导致凭据泄露；应白名单列出可信前端地址如["https://admin.example.com","https://app.example.com"]，且alloworigins为字符串数组不可逗号分隔。
AllowOrigins 用 * 还是具体域名？
生产环境直接写 "*" 是最常见也最危险的配置。它允许任意前端页面发起请求，等于把 API 暴露给全网——哪怕你没暴露敏感接口，AllowCredentials: true 一开，Cookie 就可能被恶意站点窃取。
真正安全的做法是白名单：只列出可信的前端地址，比如：
allowOrigins: ["https://admin.example.com", "https://app.example.com"]- 开发时可加
"http://localhost:8080"，但上线前必须删掉或替换 - 如果用子域名（如
dashboard.example.com和api.example.com），它们不算同源，得分别写进列表
注意：AllowOrigins 是字符串数组，不是逗号分隔的字符串；写成 "https://a.com,https://b.com" 会导致整个配置失效。
AllowOriginFunc 能动态判断来源吗？
能，而且这是处理多租户、灰度发布或临时调试场景的唯一靠谱方式。比如你有多个客户前端，域名不固定，但都带 .customer.io 后缀，就可以用正则匹配：
cors.Config{
AllowOriginFunc: func(origin string) bool {
return strings.HasSuffix(origin, ".customer.io") || origin == "http://localhost:3000"
},
AllowCredentials: true,
}
关键点：
-
AllowOriginFunc优先级高于AllowOrigins，只要它存在，后者就完全被忽略 - 函数返回
true时，Access-Control-Allow-Origin响应头会原样填入origin字符串，所以不能返回"*"（浏览器会拒绝） - 如果函数 panic 或逻辑出错，Gin 默认 fallback 到拒绝请求，不会静默放行
OPTIONS 预检失败，检查哪些 header？
浏览器发 OPTIONS 请求后卡住或报 403/500，大概率是 Access-Control-Allow-Headers 或 Access-Control-Allow-Methods 没对齐前端实际发的请求。
例如前端用 axios 发带 Authorization 和 X-Request-ID 的请求，但后端只写了 "Content-Type,Authorization"，漏了 X-Request-ID，预检就会失败。
建议做法：
- 先抓包看前端 OPTIONS 请求里
Access-Control-Request-Headers字段值，照着填进AllowHeaders -
AllowMethods必须包含前端所有用到的动词（GET,POST,PATCH等），别漏掉OPTIONS—— 它本身也要被允许 - 避免用
"*"填AllowHeaders：某些浏览器（如 Safari）不支持该写法，会直接拒绝
为什么本地开发能过，上线就跨域？
根本原因往往是部署环境和配置文件没同步。比如：
- 本地跑的是
config.yaml里的cors.enable: true，但线上用的是另一套 config，cors段被注释或压根没加载 - 用
gin-contrib/cors时，中间件注册顺序错了：比如router.Use(cors.New(...))写在了router.POST("/login", loginHandler)之后，那 login 路由就根本收不到 CORS 头 - 反向代理（Nginx / ALB）把 Origin 头过滤掉了，导致后端拿不到
c.Request.Header.Get("Origin")，白名单逻辑失效
最容易被忽略的一点：Gin 的 DefaultConfig() 会默认设 AllowAllOrigins: true，但如果你手动传了 Config 却没显式设 AllowAllOrigins 或 AllowOrigins，它会变成空数组，结果就是“不允许任何来源”——连 localhost 都 403。
