如何在Golang中处理跨域预检请求_Golang CORS Preflight处理方法

OPTIONS 请求404或被忽略是因为路由未显式注册，Go标准库和多数轻量路由不自动处理预检；需手动添加OPTIONS处理器或使用rs/cors等中间件。

为什么 OPTIONS 请求会 404 或被忽略

Go 的标准 http.ServeMux 和多数轻量路由（如 gorilla/mux 默认配置）不会自动响应预检请求。浏览器在发送带认证、自定义头或非简单方法（如 PATCH、PUT）的请求前，会先发一个 OPTIONS 请求。如果服务端没显式注册该路径的 OPTIONS 处理器，就直接 404 —— 这不是 CORS 配置问题，是路由缺失。

• 检查你是否只写了 http.HandleFunc("POST /api/user", ...)，但没写 http.HandleFunc("OPTIONS /api/user", ...)
• 用 curl -X OPTIONS -I http://localhost:8080/api/user 测试，看是否返回 200 或 405
• 若用 gin，需确保调用了 r.OPTIONS(...)；若用 echo，要启用 CORS 中间件并允许预检

手动处理预检：最小可行 OPTIONS 响应

预检响应不需要业务逻辑，只需返回正确头和 200 状态。关键是设置 Access-Control-Allow-Methods、Access-Control-Allow-Headers 与实际请求匹配，否则浏览器仍会拒绝后续请求。

func preflightHandler(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Access-Control-Allow-Origin", "https://example.com")
	w.Header().Set("Access-Control-Allow-Methods", "POST, G
ET, OPTIONS, PUT, DELETE")
	w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Requested-With")
	w.Header().Set("Access-Control-Expose-Headers", "Content-Length")
	w.Header().Set("Access-Control-Allow-Credentials", "true")
	w.Header().Set("Access-Control-Max-Age", "86400")

	// 预检必须返回 200，不能是 204
	w.WriteHeader(http.StatusOK)
}

• Access-Control-Allow-Origin 不能为 * + Access-Control-Allow-Credentials: true，否则浏览器报错
• Access-Control-Allow-Headers 必须包含前端实际发送的自定义头（比如 X-User-ID），漏一个就会失败
• 不要用 w.WriteHeader(http.StatusNoContent) —— 部分浏览器要求预检响应有 body（哪怕空）

用 rs/cors 库避免重复造轮子

手写预检逻辑易出错，推荐使用成熟中间件。官方推荐的 github.com/rs/cors 能自动拦截并响应预检，且支持细粒度控制。

import "github.com/rs/cors"

handler := http.HandlerFunc(yourHandler)
corsHandler := cors.New(cors.Options{
	AllowedOrigins:   []string{"https://example.com"},
	AllowedMethods:   []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
	AllowedHeaders:   []string{"Content-Type", "Authorization"},
	ExposedHeaders:   []string{"Content-Length"},
	AllowCredentials: true,
	MaxAge:           86400,
}).Handler(handler)

http.ListenAndServe(":8080", corsHandler)

• 它会在收到 OPTIONS 时自动返回预检响应，无需额外注册路由
• AllowedOrigins 支持通配符（如 https://*.example.com）和函数动态判断
• 注意：若你已有中间件链（如日志、JWT 验证），cors 必须放在最外层，否则预检可能被下游中间件拦截

调试预检失败的关键点

浏览器 Network 面板里看到 OPTIONS 请求状态是 canceled 或红字？说明预检根本没发出 —— 往往是前端发的请求本身触发不了预检（比如 Content-Type 是 application/json 但没带认证头），或是服务端连 OPTIONS 路由都没注册。

• 确认触发预检的条件：非简单请求（Content-Type 不是 application/x-www-form-urlencoded、multipart/form-data、text/plain 三者之一）+ 带 Authorization 头 + 自定义头 + 非 GET/HEAD/POST 方法
• 用 curl -H "Origin: https://example.com" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: Content-Type" -X OPTIONS -I http://localhost:8080/api 模拟预检
• 检查响应头是否含 Access-Control-Allow-Origin，且值与请求头 Origin 完全一致（包括协议、端口）

预检不是“开了 CORS 就完事”，它是浏览器和服务端之间一次严格的契约协商。漏掉一个头、写错一个 origin、多加一个空格，都会让整个请求链断在第一步。