Go标准库net/http默认不支持跨域,因CORS是应用层约束,需开发者显式决策;可用gorilla/handlers快速启用,或手写中间件,但须正确处理OPTIONS预检、Origin校验及Credentials限制。

为什么 net/http 默认不支持跨域?
Go 标准库的 http.ServeMux 和 http.Handler 完全不处理 CORS 相关响应头,浏览器发起跨域请求时,若服务端未显式返回 Access-Control-Allow-Origin 等头部,预检请求(OPTIONS)会失败,后续请求被拦截。这不是 bug,而是设计使然——CORS 是应用层协议约束,需开发者明确决策是否开放、对谁开放、允许哪些方法。
用 gorilla/handlers 快速启用全局 CORS
最常用且稳定的方式是引入第三方中间件,gorilla/handlers 提供了开箱即用的 CORS 选项,适配标准 http.Handler 接口。
- 安装:
go get -u github.com/gorilla/handlers - 允许任意源(开发用):
package main import ( "log" "net/http" "github.com/gorilla/handlers" ) func main() { http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "application/json") w.Write([]byte(`{"msg": "ok"}`)) }) // 包裹 handler,启用 CORS handler := handlers.CORS( handlers.AllowedOrigins([]string{"*"}), handlers.AllowedMethods([]string{"GET", "POST", "PUT", "DELETE", "OPTIONS"}), handlers.AllowedHeaders([]string{"Content-Type", "Authorization"}), )(http.DefaultServeMux) log.Fatal(http.ListenAndServe(":8080", handler)) } - 生产环境禁止用
AllowedOrigins([]string{"*"})配合AllowCredentials:浏览器会直接拒绝,必须指定明确域名,例如[]string{"https://example.com"} - 若需携带 cookie 或认证头,额外加
handlers.ExposedHeaders([]string{"X-Total-Count"})和handlers.AllowCredentials()
手动实现简单 CORS 中间件(无依赖)
当项目极轻量或需完全控制逻辑时,可手写中间件。注意:必须显式处理 OPTIONS 预检请求,否则前端发不出 POST/PUT 等非简单请求。
- 关键点:对
OPTIONS请求直接返回 200 并设置 CORS 头,不执行后续 handler - 示例中间件:
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://your-frontend.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-Expose-Headers", "X-Total-Count") w.Header().Set("Access-Control-Allow-Credentials", "true") if r.Method == "OPTIONS" { w.WriteHeader(http.StatusOK) return } next.ServeHTTP(w, r) }) } // 使用方式 http.ListenAndServe(":8080", corsMiddleware(http.DefaultServeMux)) - 切勿在 handler 内部重复设置 CORS 头(比如在
/api/data里又调一次w.Header().Set(...)),中间件已统一处理,重复设置无效且易出错 - 路径匹配逻辑由外层路由决定,该中间件作用于所有路径;如需按路径开关 CORS,应在中间件内加
if strings.HasPrefix(r.URL.Path, "/api/")判断
Access-Control-Allow-Origin 不能动态拼接域名
常见错误是试图从 r.Header.Get("Origin") 取值后白名单校验再回写——看似灵活,实则存在安全隐患和兼容陷阱。
立即学习“go语言免费学习笔记(深入)”;
- 若 Origin 不在白名单中,应返回空响应或 403,**绝不能返回
Access-Control-Allow-Origin: {origin}**,这等于开启任意源,形同裸奔 - 某些旧版浏览器(如 IE11)不支持逗号分隔多个 origin,只能设单个值;动态返回还可能被缓存,导致后续请求误用
- 正确做法:预置可信域名列表,严格比对,匹配则返回对应 origin,否则不设该 header(浏览器自然拒绝)
- 示例安全写法:
allowedOrigins := map[string]bool{ "https://app.example.com": true, "https://staging.example.com": true, } origin := r.Header.Get("Origin") if allowedOrigins[origin] { w.Header().Set("Access-Control-Allow-Origin", origin) w.Header().Set("Access-Control-Allow-Credentials", "true") }
AllowedOrigins 是否含 *、是否启用了 AllowCredentials、是否漏了 OPTIONS 处理——这三个点错一个,前端就静默失败。










