本文探讨在Go语言后端处理跨域资源共享（CORS）预检（OPTIONS）请求的最佳实践。我们将介绍使用`net/http`和`Gorilla Mux`的常见方法，并重点推荐一种基于HTTP处理程序包装器（wrapper）的优雅模式，以实现逻辑分离和代码复用，从而高效、规范地响应CORS预检请求，确保跨站HTTP通信的顺畅进行。
在构建RESTful API时，尤其当前端应用部署在不同域名或端口时，跨域资源共享（CORS）机制是不可避免的。浏览器为了安全，会强制执行同源策略。对于一些“非简单请求”（例如，使用了PUT、DELETE方法，或者包含了自定义HTTP头的请求），浏览器在发送实际请求之前，会先发送一个HTTP OPTIONS方法请求，这被称为“预检请求”（Preflight Request）。服务器需要正确响应这些预检请求，告知浏览器允许的跨域访问策略，否则实际请求将被浏览器阻止。
本文将深入探讨在Go语言环境下，如何高效且优雅地处理这些CORS预检请求。
理解CORS预检请求
当浏览器检测到跨域的“非简单请求”时，它会首先发送一个OPTIONS请求到目标服务器。这个请求包含了一系列特殊的HTTP头，如Access-Control-Request-Method（请求将使用的实际HTTP方法）和Access-Control-Request-Headers（请求将携带的自定义头）。服务器的职责是检查这些头，并以相应的Access-Control-Allow-*系列头作为响应，明确告知浏览器是否允许该跨域请求。如果预检成功，浏览器才会发送实际的请求。
Go语言中处理预检请求的常见方法
在Go语言中，处理CORS预检请求有多种方式，以下是两种常见但可能不够优雅的实现：
1. 在每个处理函数内部进行方法判断
这是最直接的方法，在每个HTTP处理函数中，通过r.Method判断请求方法是否为OPTIONS，然后分别处理。
package main
import (
"fmt"
"net/http"
)
func AddResourceHandler(rw http.ResponseWriter, r *http.Request) {
switch r.Method {
case http.MethodOptions:
// 处理预检请求
rw.Header().Set("Access-Control-Allow-Origin", "http://localhost:3000")
rw.Header().Set("Access-Control-Allow-Methods", "PUT, OPTIONS")
rw.Header().Set("Access-Control-Allow-Headers", "Content-Type")
rw.WriteHeader(http.StatusOK)
return
case http.MethodPut:
// 处理实际的PUT请求
fmt.Fprintf(rw, "Received PUT request for resource.")
default:
http.Error(rw, "Method not allowed", http.StatusMethodNotAllowed)
}
}
func main() {
http.HandleFunc("/someresource/item", AddResourceHandler)
fmt.Println("Server listening on :8080")
http.ListenAndServe(":8080", nil)
}优点： 简单直观，无需额外依赖。 缺点： 逻辑分散，每个需要CORS支持的路由都需要重复编写预检处理代码，导致代码冗余和维护困难。
2. 使用路由库（如Gorilla Mux）为OPTIONS方法注册独立路由
使用像Gorilla Mux这样的路由库，可以为不同的HTTP方法注册不同的处理函数。这意味着你可以为OPTIONS方法注册一个专门的预检处理函数。
package main
import (
"fmt"
"net/http"
"github.com/gorilla/mux"
)
func PreflightAddResourceHandler(rw http.ResponseWriter, r *http.Request) {
rw.Header().Set("Access-Control-Allow-Origin", "http://localhost:3000")
rw.Header().Set("Access-Control-Allow-Methods", "PUT, OPTIONS")
rw.Header().Set("Access-Control-Allow-Headers", "Content-Type")
rw.WriteHeader(http.StatusOK)
}
func AddResourceHandler(rw http.ResponseWriter, r *http.Request) {
fmt.Fprintf(rw, "Received PUT request for resource.")
}
func main() {
r := mux.NewRouter()
r.HandleFunc("/someresource/item", AddResourceHandler).Methods(http.MethodPut)
r.HandleFunc("/someresource/item", PreflightAddResourceHandler).Methods(http.MethodOptions)
fmt.Println("Server listening on :8080")
http.ListenAndServe(":8080", r)
}优点： 将预检逻辑从实际业务逻辑中分离，路由结构更清晰。 缺点： 仍然需要在每个受CORS影响的路径上注册一个OPTIONS处理函数，如果有很多路径，依然存在一定程度的重复劳动。
推荐实践：使用HTTP处理程序包装器（Middleware）
最优雅且可复用的方式是创建一个HTTP处理程序包装器（或称为中间件）。这个包装器接收一个http.Handler作为参数，并返回一个新的http.HandlerFunc。在返回的函数中，它会首先检查请求是否为OPTIONS预检请求。如果是，它会处理CORS响应头并直接返回；如果不是，它会将请求传递给原始的处理程序。
这种模式实现了关注点分离，将CORS逻辑从业务逻辑中完全解耦，并且可以轻松地应用于任何HTTP处理程序。
包装器实现示例
package main
import (
"fmt"
"net/http"
"time" // 用于设置Access-Control-Max-Age
"github.com/gorilla/mux" // 也可以与标准库的http.ServeMux结合使用
)
// corsMiddleware 是一个HTTP处理程序包装器，用于处理CORS预检请求。
// 它接收一个http.Handler并返回一个新的http.HandlerFunc。
func corsMiddleware(next http.Handler) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
// 设置通用的CORS响应头
// 生产环境应将 "*" 替换为具体的允许来源，例如 "http://yourfrontend.com"
w.Header().Set("Access-Control-Allow-Origin", "*")
// 允许的HTTP方法，根据你的API实际支持的方法进行设置
w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
// 允许的请求头，包括Content-Type和自定义头
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Custom-Header")
// 预检结果的缓存时间，单位秒。浏览器在此时间内不再发送重复预检请求。
w.Header().Set("Access-Control-Max-Age", "86400") // 24小时
// 如果是预检请求 (OPTIONS方法)，则直接返回200 OK
if r.Method == http.MethodOptions {
w.WriteHeader(http.StatusOK)
return // 预检请求处理完毕，不再执行后续的处理程序
}
// 如果不是预检请求，则将请求传递给链中的下一个处理程序（即原始业务逻辑处理程序）
next.ServeHTTP(w, r)
}
}
// resourceHandler 模拟一个实际的RESTful业务逻辑处理函数
func resourceHandler(w http.ResponseWriter, r *http.Request) {
if r.Method == http.MethodPut {
w.WriteHeader(http.StatusOK)
fmt.Fprintf(w, "Received PUT request for resource: %s", r.URL.Path)
return
}
if r.Method == http.MethodGet {
w.WriteHeader(http.StatusOK)
fmt.Fprintf(w, "Received GET request for resource: %s", r.URL.Path)
return
}
http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
}
func main() {
// 实例化一个普通的HTTP处理程序
myResourceHandler := http.HandlerFunc(resourceHandler)
// 使用corsMiddleware包装器来处理CORS，将其应用于业务处理程序
// 这里使用Gorilla Mux作为路由示例，但同样适用于标准库的http.ServeMux
r := mux.NewRouter()
r.Handle("/api/item", corsMiddleware(myResourceHandler)).Methods(http.MethodGet, http.MethodPut, http.MethodOptions)
// 启动服务器
fmt.Println("Server listening on :8080")
http.ListenAndServe(":8080", r)
}代码解析与注意事项
-
corsMiddleware函数：
- 它接收一个http.Handler接口类型的参数next，这代表了链中的下一个处理程序（通常是你的业务逻辑处理程序）。
- 它返回一个http.HandlerFunc，这是一个函数类型，实现了http.Handler接口的ServeHTTP方法。
- 在返回的函数内部，首先设置了所有必要的CORS响应头。
- 接着，判断r.Method == http.MethodOptions。如果是预检请求，设置200 OK状态码并直接返回，不再调用next.ServeHTTP(w, r)，因为预检请求本身没有实际的业务数据需要处理。
- 如果不是预检请求，则调用next.ServeHTTP(w, r)，将请求传递给原始的业务逻辑处理程序。
-
CORS响应头配置：
- Access-Control-Allow-Origin: 关键。指定允许访问资源的源。开发时常用*表示允许所有源，但生产环境务必将其替换为你的前端应用的具体域名或IP，以增强安全性。例如：http://yourfrontend.com。如果需要支持多个源，可以动态判断Origin请求头，并将其回写到Access-Control-Allow-Origin。
- Access-Control-Allow-Methods: 列出允许实际请求使用的HTTP方法。例如：GET, POST, PUT, DELETE, OPTIONS。
- Access-Control-Allow-Headers: 列出允许实际请求携带的非简单请求头。如果前端使用了自定义头（如Authorization、X-Custom-Header），必须在此处列出。
- Access-Control-Max-Age: 预检请求的结果可以被浏览器缓存的时间，单位为秒。在此时间内，浏览器对同一资源的相同预检请求将直接使用缓存结果，而不会再次发送OPTIONS请求。这可以减少网络开销。常见的设置是几小时（例如86400秒，即24小时）。
- Access-Control-Allow-Credentials: 如果你的前端需要发送带有凭据（如Cookie、HTTP认证）的跨域请求，并且服务器也需要接收这些凭据，则需要将此头设置为true。*注意：如果设置了Access-Control-Allow-Credentials: true，那么Access-Control-Allow-Origin就不能设置为``，必须是具体的源。**
-
集成到路由：
- 无论是Go标准库的http.ServeMux还是Gorilla Mux等第三方路由，都可以通过http.Handle("/path", corsMiddleware(yourHandler))或router.Handle("/path", corsMiddleware(yourHandler))的方式将CORS中间件应用到特定的路由上。
总结
通过使用HTTP处理程序包装器模式，我们可以将CORS预检请求的处理逻辑集中管理，实现代码的模块化和复用。这种方法不仅使代码更清晰、更易于维护，而且提供了一个健壮且可配置的CORS解决方案。在实际项目中，可以根据需求进一步完善corsMiddleware，例如从配置文件中加载允许的源、方法和头，或者处理带有凭据的CORS请求。对于大型项目，许多Go web框架（如Gin、Echo、Chi）也提供了内置的CORS中间件，它们通常也是基于类似的包装器模式实现的，可以更便捷地配置和使用。
