Go HTTP服务中CORS需显式处理OPTIONS预检请求，正确设置Access-Control-Allow-Origin（不能为*且带凭据）、配置反向代理透传头、合理使用gorilla/handlers或手写中间件，并按路径/方法精细化控制策略。
Go HTTP 服务里 Access-Control-Allow-Origin 头没生效？
不是加了就完事——Go 的 net/http 默认不自动处理预检（OPTIONS 请求），浏览器发的预检被直接 404 或 501，跨域照样失败。
实操建议：
- 必须显式注册
OPTIONS路由，或在中间件里拦截并返回 204；否则哪怕响应头全对，预检也过不去 -
Access-Control-Allow-Origin不能设为*同时带凭据（credentials: true），得写具体域名，比如https://example.com - 如果用了反向代理（如 Nginx），确保它没过滤掉自定义响应头——
Access-Control-Allow-*类头默认被丢弃，要显式配置add_header或proxy_pass_request_headers on
用 gorilla/handlers.CORS() 为什么还是报错？
这个包封装得看似省事，但参数组合不对，很容易漏掉关键约束。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 前端报
No 'Access-Control-Allow-Origin' header is present：可能传了handlers.AllowedOrigins([]string{"*"})，但实际需要的是handlers.AllowedOrigins([]string{"https://a.com", "https://b.com"})（*是字符串字面量，不是通配符） - 带 cookie 的请求失败：忘了加
handlers.ExposedHeaders([]string{"X-Total-Count"})或handlers.AllowCredentials()，且两者必须同时启用才有效 - 预检缓存时间太短：默认
Access-Control-Max-Age是 5 秒，高频请求下反复预检，可手动设为handlers.MaxAge(3600)
自己写中间件比用库更可控？
是的，尤其当路由逻辑复杂、需按路径/方法差异化控制 CORS 策略时，手写几行反而更稳。
一个轻量但完整的中间件示例：
func corsMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Access-Control-Allow-Origin", "https://myapp.com")
w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
w.Header().Set("Access-Control-Allow-Credentials", "true")
if r.Method == "OPTIONS" {
w.WriteHeader(http.StatusNoContent)
return
}
next.ServeHTTP(w, r)
})
}
注意点：
-
Access-Control-Allow-Headers必须包含前端实际发送的自定义头（比如X-Request-ID），否则预检失败 - 中间件顺序很重要：必须在路由分发前执行，否则
r.Method == "OPTIONS"可能进不到你写的中间件里 - 不要在 handler 里重复调用
w.Header().Set()—— Go 的 Header 是 map，后设覆盖前设，但某些字段（如Content-Type）一旦写入 body 就不可改
生产环境要不要关 CORS？
不能关，但可以收窄。开发时设 * 图省事，上线后必须限制来源、禁用凭据（除非真需要）、暴露最少必要头。
容易被忽略的地方：
- 本地开发用
localhost:3000，但上线后可能是app.example.com+ CDN 域名，CORS 白名单得同步更新，别只改前端地址忘了后端配置 - 微服务间调用走内网，但前端直连某个服务时仍走公网入口——这时 CORS 是给浏览器看的，服务间通信不受影响，别误以为“内部调用就不用配”
- 如果用了 gRPC-Gateway 或其他 HTTP 包装层，确认它没重置或覆盖你设置的 CORS 头
跨域不是开关题，是策略题。每个头、每条规则、每次预检，都得和前端真实行为对得上。
