Go 服务器处理 CORS 预检请求的最佳实践

本文旨在深入探讨在go语言后端服务中，如何高效且优雅地处理跨域资源共享（cors）预检（options）请求。我们将分析常见的处理方式，并重点推荐一种基于处理器包装（handler wrapping）的模式，以实现逻辑分离、代码复用和维护性提升。通过具体代码示例，读者将掌握在`net/http`环境中构建健壮cors处理机制的方法。

理解 CORS 预检请求

跨域资源共享（CORS）是一种浏览器安全机制，它允许网页从不同域的服务器请求资源。当浏览器检测到某些“非简单请求”（如带有自定义HTTP头、使用PUT/DELETE方法或非简单内容类型）时，它会在实际请求发送之前，自动发送一个HTTP OPTIONS请求，即“预检请求”（Preflight Request）。这个预检请求的目的是询问服务器，是否允许发送后续的实际请求。服务器必须正确响应这些预检请求，告知浏览器允许的源、方法、头部等信息，否则浏览器将阻止实际请求的发送。

预检请求的关键在于服务器需要返回一系列Access-Control-Allow-*响应头，例如：

• Access-Control-Allow-Origin: 允许访问该资源的源。
• Access-Control-Allow-Methods: 允许访问该资源的方法（如GET, POST, PUT, DELETE）。
• Access-Control-Allow-Headers: 允许在请求中使用的自定义头部。
• Access-Control-Max-Age: 预检请求的结果可以缓存的时间（秒）。

传统处理方式及其局限性

在Go语言中，使用标准库net/http或流行的路由库如Gorilla/mux时，开发者可能会自然而然地想到以下两种处理预检请求的方式：

1. 在处理器函数内部使用 switch 判断方法：

   func ResourceHandler(w http.ResponseWriter, r *http.Request) {
       switch r.Method {
       case "OPTIONS":
           // 处理预检请求逻辑
           w.Header().Set("Access-Control-Allow-Origin", "*")
           w.Header().Set("Access-Control-Allow-Methods", "PUT, OPTIONS")
           w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
           w.WriteHeader(http.StatusOK)
       case "PUT":
           // 处理实际的PUT请求逻辑
           w.Write([]byte("Resource updated successfully!"))
       default:
           http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
       }
   }

   这种方式的缺点是，每个需要CORS支持的处理器函数都需要重复编写预检逻辑，导致代码冗余且难以维护。

2. 为每个路径注册单独的 OPTIONS 处理器（使用 Gorilla/mux）：

   router := mux.NewRouter()
   router.HandleFunc("/api/resource", ActualResourceHandler).Methods("PUT")
   router.HandleFunc("/api/resource", PreflightResourceHandler).Methods("OPTIONS")
   
   func PreflightResourceHandler(w http.ResponseWriter, r *http.Request) {
       // 处理预检请求逻辑
       w.Header().Set("Access-Control-Allow-Origin", "*")
       w.Header().Set("Access-Control-Allow-Methods", "PUT, OPTIONS")
       w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
       w.WriteHeader(http.StatusOK)
   }
   
   func ActualResourceHandler(w http.ResponseWriter, r *http.Request) {
       // 处理实际的PUT请求逻辑
       w.Write([]byte("Resource updated successfully!"))
   }

   虽然将预检逻辑分离到独立的函数中，但仍然需要在每个受CORS影响的路由上重复注册OPTIONS处理器，且预检逻辑本身可能仍有重复。

推荐方案：处理器包装（Handler Wrapping）模式

为了更优雅地处理CORS预检请求，Go社区推崇使用“处理器包装”模式，这是一种常见的中间件（Middleware）实现方式。通过将CORS处理逻辑封装在一个高阶函数中，我们可以将其应用于任何需要CORS支持的HTTP处理器，从而实现逻辑的复用和分离。

核心思想

创建一个corsHandler函数，它接收一个http.Handler作为参数，并返回一个新的http.HandlerFunc。这个新的http.HandlerFunc会在内部判断请求方法。如果方法是OPTIONS，它会处理预检逻辑并直接返回；否则，它会将请求传递给原始的http.Handler进行处理。

实现 corsHandler

package main

import (
    "log"
    "net/http"
    "time"
)

// corsHandler 是一个高阶函数，用于包装实际的HTTP处理器，处理CORS预检请求。
func corsHandler(next http.Handler) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // 设置通用的CORS响应头
        // 允许所有来源访问，实际应用中应限制为已知来源
        w.Header().Set("Access-Control-Allow-Origin", "*")
        // 允许的HTTP方法，这里示例了PUT和OPTIONS
        w.Header().Set("Access-Control-Allow-Methods", "PUT, GET, POST, DELETE, OPTIONS")
        // 允许的请求头，实际应用中应根据需要添加
        w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
        // 预检请求结果的缓存时间（秒）
        w.Header().Set("Access-Control-Max-Age", "86400") // 24小时

        // 如果是OPTIONS请求，则直接处理预检并返回
        if r.Method == "OPTIONS" {
            w.WriteHeader(http.StatusOK)
            return
        }

        // 如果不是OPTIONS请求，则将请求传递给被包装的实际处理器
        next.ServeHTTP(w, r)
    }
}

// actualResourceHandler 是处理实际业务逻辑的HTTP处理器
func actualResourceHandler(w http.ResponseWriter, r *http.Request) {
    log.Printf("Received %s request for /api/resource", r.Method)
    switch r.Method {
    case "PUT":
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("Resource updated successfully!"))
    case "GET":
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("Resource fetched successfully!"))
    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
}

func main() {
    // 创建一个实际业务逻辑的处理器
    resourceHandler := http.HandlerFunc(actualResourceHandler)

    // 使用 corsHandler 包装实际的处理器
    // 这样，所有对 "/api/resource" 的请求都会先经过 CORS 逻辑处理
    http.Handle("/api/resource", corsHandler(resourceHandler))

    // 启动HTTP服务器
    log.Println("Server starting on port 8080...")
    server := &http.Server{
        Addr:         ":8080",
        ReadTimeout:  5 * time.Second,
        WriteTimeout: 10 * time.Second,
        IdleTimeout:  120 * time.Second,
    }
    log.Fatal(server.ListenAndServe())
}

代码解析与优势

1. corsHandler 函数：
   • 它接收一个 http.Handler 接口类型的参数 next，这代表了实际处理业务逻辑的处理器。
   • 它返回一个 http.HandlerFunc，这是一个函数类型，实现了 http.Handler 接口的 ServeHTTP 方法。
   • 在返回的函数内部，首先设置了CORS相关的响应头，这些头对于预检请求和实际请求的响应都有效。
   • 接着，通过 if r.Method == "OPTIONS" 判断当前请求是否为预检请求。
     • 如果是预检请求，则设置状态码为 http.StatusOK (200 OK) 并直接返回，不再将请求传递给 next 处理器。这是因为预检请求本身不包含业务数据，只需告知浏览器CORS策略即可。
     • 如果不是预检请求，则调用 next.ServeHTTP(w, r)，将请求和响应写入器传递给实际的业务逻辑处理器进行处理。
2. main 函数中的应用：
   • 我们首先定义了 actualResourceHandler，这是纯粹的业务逻辑处理器，不包含任何CORS相关的代码。
   • 然后，通过 http.Handle("/api/resource", corsHandler(resourceHandler))，我们将业务处理器 resourceHandler 包装在 corsHandler 中，并注册到 /api/resource 路径。
   • 这样，所有发往 /api/resource 的请求（包括OPTIONS预检请求和GET/PUT等实际请求）都会首先进入 corsHandler。

这种包装模式的优势显而易见：

• 代码复用： CORS处理逻辑集中在一个地方，避免了重复编写。
• 职责分离： 业务处理器只关注业务逻辑，CORS逻辑由 corsHandler 负责，使得代码更清晰、更易于理解和维护。
• 模块化： corsHandler 可以作为一个独立的中间件模块，轻松地应用于不同的路由或整个服务器。

注意事项与进阶

• Access-Control-Allow-Origin 的精确控制： 在示例中使用了 * 允许所有来源，但在生产环境中，这通常是不安全的。应根据 r.Header.Get("Origin") 动态设置允许的源，或者维护一个白名单。

  // 示例：根据白名单动态设置Origin
  allowedOrigins := map[string]bool{
      "http://localhost:3000": true,
      "https://your-frontend.com": true,
  }
  origin := r.Header.Get("Origin")
  if allowedOrigins[origin] {
      w.Header().Set("Access-Control-Allow-Origin", origin)
  } else {
      // 如果不在白名单，可以不设置Origin头，或直接返回错误
      // 对于预检请求，通常直接返回200 OK但没有Allow-Origin头，浏览器会报错
  }

• Access-Control-Allow-Headers 和 Access-Control-Allow-Methods： 同样，这些头也应根据实际需求精确设置，避免暴露不必要的权限。

• 错误处理： 对于不符合CORS策略的请求（例如，Origin不在白名单），可以选择返回一个非200状态码，或者不设置CORS相关头，浏览器会自行处理拒绝。

• 第三方库： 对于更复杂的CORS需求，可以考虑使用现有的Go CORS中间件库，如 github.com/rs/cors。这些库通常提供了更丰富的配置选项和更健壮的错误处理机制，能够更好地处理动态策略和复杂场景。例如：

  import "github.com/rs/cors"
  
  func main() {
      // ...
      c := cors.New(cors.Options{
          AllowedOrigins:   []string{"http://localhost:3000", "https://your-frontend.com"},
          AllowedMethods:   []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
          AllowedHeaders:   []string{"Content-Type", "Authorization"},
          ExposedHeaders:   []string{"Link"},
          AllowCredentials: true,
          MaxAge:           86400,
      })
  
      handler := c.Handler(http.HandlerFunc(actualResourceHandler))
      http.Handle("/api/resource", handler)
      // ...
  }

  这种方式更加简洁和强大，推荐在生产环境中使用。

总结

在Go服务器中处理CORS预检请求，最佳实践是采用处理器包装（Handler Wrapping）模式。这种模式将CORS处理逻辑与业务逻辑清晰分离，提升了代码的模块化、可读性和可维护性。通过自定义corsHandler或利用成熟的第三方CORS中间件库，开发者可以高效且安全地构建支持跨域请求的Go后端服务。在实际部署时，务必注意Access-Control-Allow-Origin等头的精确配置，以确保安全性。