本文详解 Go 应用中 CORS 预检（OPTIONS）失败的常见原因及解决方案，涵盖 rs/cors 库的正确配置、自定义中间件实现，并强调 Access-Control-Allow-Headers 与 AllowedMethods 中必须显式包含 OPTIONS 的关键实践。
本文详解 go 应用中 cors 预检（options）失败的常见原因及解决方案，涵盖 `rs/cors` 库的正确配置、自定义中间件实现，并强调 `access-control-allow-headers` 与 `allowedmethods` 中必须显式包含 `options` 的关键实践。
在使用 Go 构建 RESTful 后端并与前端（如 Angular）交互时，CORS（跨域资源共享）问题极为常见。尤其当浏览器发起带自定义请求头（如 access_token）或非简单方法（如 PATCH）的请求时，会先触发预检（Preflight）OPTIONS 请求。若后端未正确响应此预检请求，整个 API 调用将被浏览器拦截——这正是你遇到的问题核心。
你的原始代码中存在两个关键疏漏：
AllowedMethods缺少"OPTIONS"rs/cors库要求AllowedMethods显式包含"OPTIONS"，否则预检请求会被拒绝（即使Handler本身未注册OPTIONS路由）。cors中间件需主动处理OPTIONS并返回正确的响应头，而非交由下游路由。AllowedHeaders未覆盖实际请求头
前端请求中携带了access_token头，但你的AllowedHeaders仅声明了"a_custom_header"和"content_type"（注意：content_type是错误写法，应为Content-Type）。浏览器会严格比对，不匹配则预检失败。
✅ 正确配置 rs/cors 的修复示例：
handler := cors.New(cors.Options{
AllowedOrigins: []string{"*"}, // 生产环境建议指定具体域名，如 []string{"https://your-app.com"}
AllowedMethods: []string{"GET", "POST", "PATCH", "OPTIONS"}, // ✅ 必须包含 OPTIONS
AllowedHeaders: []string{
"Access-Token", // ✅ 匹配请求中的 access_token（注意大小写不敏感，但建议规范）
"Content-Type", // ✅ 修正为标准 header 名
"Accept", // ✅ 推荐添加：Angular 等框架常发送
"Accept-Language",
},
// 可选：允许携带凭证（cookies / auth headers）
// AllowCredentials: true,
}).Handler(router)
⚠️ 注意事项：
-
AllowedOrigins: []string{"*"}在启用AllowCredentials: true时不可用，必须指定明确源（如https://example.com）。 -
Access-Control-Allow-Headers的值必须与客户端Access-Control-Request-Headers完全匹配（忽略大小写），且Content-Type必须拼写准确。 -
rs/cors会自动处理OPTIONS请求并返回204 No Content，无需手动注册router.HandleFunc("...", ...)处理OPTIONS。
? 替代方案：轻量级自定义 CORS 中间件
若希望更透明地控制逻辑或避免依赖第三方库，可手写中间件（如答案中所示）。以下为增强版实现，支持动态 Origin 白名单和更健壮的预检处理：
func CORS(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
origin := r.Header.Get("Origin")
if origin != "" {
// 生产环境建议校验 origin 是否在白名单内
w.Header().Set("Access-Control-Allow-Origin", origin)
w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, PATCH, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers",
"Access-Token, Content-Type, Accept, Accept-Language, X-Requested-With")
w.Header().Set("Access-Control-Expose-Headers", "X-Total-Count") // 如需暴露自定义响应头
}
// 预检请求直接返回，不进入后续 handler
if r.Method == "OPTIONS" {
w.WriteHeader(http.StatusOK)
return
}
next.ServeHTTP(w, r)
})
}
// 使用方式
http.ListenAndServe(":8000", CORS(router))
? 总结：
CORS 预检失败的根因几乎总是服务端响应头缺失或不匹配。务必确保：
① OPTIONS 方法显式列入允许方法列表；
② 所有客户端发送的自定义请求头（如 access_token）均出现在 AllowedHeaders 中；
③ Content-Type 等标准头名拼写准确；
④ 开发阶段可用浏览器 DevTools 的 Network → Options 请求查看响应头，验证 Access-Control-Allow-* 是否完整返回。
遵循以上原则，即可稳定支撑 Angular、React 等现代前端框架与 Go 后端的跨域通信。
