go http server默认不支持跨域，需手动添加cors响应头或使用rs/cors等中间件；必须处理options预检、校验origin、设置vary: origin及合理配置access-control-allow-origin与allowcredentials。
Go HTTP Server 默认不支持跨域，必须手动添加响应头
浏览器发起的跨域请求会被直接拦截，除非服务端明确允许。Go 的 net/http 包默认不设置任何 CORS 相关响应头，所以即使接口逻辑正常，前端 fetch 也会报 Access to fetch at '...' from origin '...' has been blocked by CORS policy 错误。
最简解决方式是给每个 handler 加上固定响应头：
func myHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
if r.Method == "OPTIONS" {
w.WriteHeader(http.StatusOK)
return
}
// 实际业务逻辑
w.Write([]byte("OK"))
}
-
Access-Control-Allow-Origin设为*仅适用于无认证的公开接口；若需携带 cookie 或 Authorization，必须指定具体域名（如https://example.com），且不能用通配符 - 必须显式处理
OPTIONS预检请求，否则浏览器在发送 POST/PUT 等请求前会失败 -
Access-Control-Allow-Credentials: true和Access-Control-Allow-Origin: *互斥，同时设置会导致浏览器拒绝请求
使用第三方中间件（如 rs/cors）更安全可控
手写 header 容易遗漏细节（比如未处理预检、未限制 origin、未清理重复 header），推荐用成熟中间件。目前最常用的是 rs/cors：
import "github.com/rs/cors"
handler := cors.New(cors.Options{
AllowedOrigins: []string{"https://example.com", "http://localhost:3000"},
AllowedMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
AllowedHeaders: []string{"Content-Type", "Authorization"},
ExposedHeaders: []string{"X-Total-Count"},
AllowCredentials: true,
}).Handler(yourMux)
http.ListenAndServe(":8080", handler)
-
AllowedOrigins支持通配符前缀匹配（如https://*.example.com），但不支持任意子域名通配（https://*.com无效） - 如果后端要读取前端 cookie，必须同时设
AllowCredentials: true且前端 fetch 要加credentials: 'include' - 该中间件会自动拦截并响应
OPTIONS请求，无需额外路由配置
gin 框架中启用 CORS 需注意中间件注册顺序
在 gin 中，cors 中间件必须在路由定义之前注册，否则无法覆盖默认行为：
立即学习“go语言免费学习笔记（深入）”；
r := gin.Default()
r.Use(cors.New(cors.Config{
AllowOrigins: []string{"https://example.com"},
AllowMethods: []string{"GET", "POST", "PUT", "DELETE"},
AllowHeaders: []string{"Content-Type", "Authorization"},
ExposeHeaders: []string{"Content-Length"},
AllowCredentials: true,
}))
r.GET("/api/data", getData)
- 如果把
r.Use(...)放在r.GET(...)之后，CORS 头不会生效——因为 gin 的中间件链是注册时确定的，不是按调用顺序执行 - gin 自带的
gin-contrib/cors已归档，建议直接用rs/cors（它兼容标准http.Handler，也能 wrap gin.Engine） - 开发环境可临时用
AllowOrigins: []string{"*"}，但上线前务必替换为精确域名列表
生产环境必须校验 Origin 而非硬编码白名单
硬编码 AllowedOrigins 在多租户或动态域名场景下不可行。更健壮的做法是运行时解析并校验 Origin 请求头：
func validateOrigin(origin string) bool {
if origin == "" {
return false
}
u, err := url.Parse(origin)
if err != nil {
return false
}
allowedHosts := map[string]bool{
"example.com": true,
"staging.example.com": true,
}
return allowedHosts[u.Hostname()]
}
// 在 handler 开头：
origin := r.Header.Get("Origin")
if validateOrigin(origin) {
w.Header().Set("Access-Control-Allow-Origin", origin)
w.Header().Set("Vary", "Origin") // 告诉 CDN 缓存需区分 Origin
}
- 必须加
Vary: Origin响应头，否则反向代理（如 Nginx、Cloudflare）可能缓存错误的 CORS 响应 - 不要只检查 host，还要验证 scheme（
https://vshttp://），尤其当你的服务同时支持两者时 - 正则匹配 origin 有风险（如
.*\.example\.com可能被绕过），优先用白名单 map 查找
Access-Control-Max-Age）。没设 Vary 会导致跨域响应被错误复用；没设 Max-Age 则每次请求前都发一次 OPTIONS，增加延迟。 
