Golang实现跨域请求支持方法

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") 取值后白名单校验再回写——看似灵活，实则存在安全隐患和兼容陷阱。

• 若 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")
  }