应使用 gin-contrib/cors 而非手写 header，因其自动处理 OPTIONS 预检、校验 origin 白名单、注入 expose headers 且兼容中间件链；生产环境须显式配置 AllowCredentials、AllowOrigins 等，禁用 cors.Default()。
为什么直接写 Cors() 会放行所有域名
因为 Gin 官方推荐的 gin-contrib/cors 默认配置里，Config{}.AllowAllOrigins = true，这等于把 Access-Control-Allow-Origin: * 直接塞进响应头——看似方便，但一旦接口要带凭证（如 Cookie 或 Authorization），浏览器就会拒绝响应。真正需要的是按域名精确放行。
如何用 cors.New() 配置白名单并支持凭证
必须显式传入 origins 列表，并设 AllowCredentials: true，否则即使域名匹配，带 withCredentials: true 的前端请求仍会失败。
-
origins必须是完整协议+域名（如"https://example.com"），不能写"example.com"或"*.example.com"（通配符仅在AllowAllOrigins=true时有效） - 若需支持多个域名，用切片传入：
[]string{"https://a.com", "https://b.com"} -
AllowCredentials: true必须配合AllowHeaders显式声明允许的头字段，比如["Content-Type", "Authorization"] - 别漏掉
ExposeHeaders，否则前端 JS 拿不到自定义响应头（如X-Request-ID）
router.Use(cors.New(cors.Config{
AllowOrigins: []string{"https://a.com", "https://b.com"},
AllowMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
AllowHeaders: []string{"Content-Type", "Authorization"},
AllowCredentials: true,
ExposeHeaders: []string{"X-Request-ID"},
}))
OPTIONS 请求 404 或重复执行中间件怎么办
Gin 默认不自动处理 OPTIONS，如果路由没显式注册或没被 CORS 中间件覆盖，就会 404；更隐蔽的问题是：某些客户端（尤其 iOS WebView）会发带 body 的 OPTIONS，而 Gin 的 cors 默认只处理无 body 的预检，导致后续中间件（如 JWT 验证）误判为非法请求。
- 确保
AllowMethods包含"OPTIONS"，否则预检直接被拦截 - 不要在路由上单独写
router.OPTIONS(...)，CORS 中间件已内置处理逻辑 - 若发现 OPTIONS 被其他中间件拦截（比如 JWT 验证器对空 token 报错），检查中间件顺序——CORS 必须放在鉴权中间件之前
- 调试时用
curl -X OPTIONS -H "Origin: https://a.com" -I http://localhost:8080/api/user看响应头是否含Access-Control-Allow-Origin
开发环境 localhost 端口不同怎么加白名单
本地开发时前端常跑在 http://localhost:3000，后端是 http://localhost:8080，这个组合必须明确写进 AllowOrigins。但硬编码会导致上线要改代码，建议用环境变量动态加载。
立即学习“go语言免费学习笔记（深入）”；
- 开发时加
"http://localhost:3000"和"http://127.0.0.1:3000"（Safari 有时认 IP） - 用
os.Getenv("CORS_ORIGINS")解析逗号分隔的字符串，避免 if/else 分支 - 切记：HTTP 协议、端口号、斜杠结尾都影响匹配，
"http://localhost:3000"≠"http://localhost:3000/" - 测试阶段可临时加
"http://localhost:*"，但上线前必须删掉——浏览器不支持端口通配
Origin，且确保后端读取的是真实请求头而非代理伪造的。 
