如何在 Gin 框架中正确实现 CORS 中间件

本文详解 gin 中 cors 中间件的常见错误与正确写法，重点解决 options 预检请求后接口无响应的问题，提供可直接使用的生产级中间件代码及关键配置说明。

在使用 Gin 构建 restful API 时，前端跨域请求（如来自 http://localhost:3000 调用 http://localhost:8080/api）会触发浏览器的预检（Preflight）机制，发送 OPTIONS 请求。若服务端未正确响应该请求，后续实际请求（如 POST 或 GET）将被浏览器拦截，表现为“状态码 200 但无后续响应”——这正是原问题的核心现象。

根本原因在于：CORS 中间件中对 OPTIONS 请求的处理逻辑存在两处关键缺陷：

1. 错误使用 c.AbortWithStatus(200)：虽然返回了 200，但 200 OK 不是预检请求的标准响应状态；RFC 规范要求预检成功应返回 204 No Content（无响应体、语义明确），部分浏览器（尤其是 chrome 和 safari）对非标准状态码容忍度低，可能导致预检失败后静默终止流程；
2. access-Control-Allow-Credentials: “true” 与 Access-Control-Allow-Origin: “*” 冲突：当允许携带凭据（如 cookie、Authorization header）时，Origin 值不能为通配符 *，否则浏览器会拒绝请求。必须指定明确的源（如 http://localhost:3000）或动态匹配（见下文进阶方案）。

以下是修正后的、经生产验证的 CORS 中间件实现：

func CORSMiddleware() gin.HandlerFunc {     return func(c *gin.Context) {         // 允许指定源（开发环境可用具体地址，生产建议动态校验）         origin := c.Request.Header.Get("Origin")         if origin != "" {             // 安全起见：仅允许白名单内的 Origin             allowedOrigins := []string{"http://localhost:3000", "https://your-app.com"}             for _, allowed := range allowedOrigins {                 if origin == allowed {                     c.Writer.Header().Set("Access-Control-Allow-Origin", origin)                     break                 }             }         }          c.Writer.Header().Set("Access-Control-Allow-Credentials", "true")         c.Writer.Header().Set("Access-Control-Allow-Headers",              "Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization, accept, origin, Cache-Control, X-Requested-With")         c.Writer.Header().Set("Access-Control-Allow-Methods", "POST, GET, PUT, PATCH, DELETE, OPTIONS")          // 关键：OPTIONS 请求必须返回 204，且立即终止中间件链         if c.Request.Method == "OPTIONS" {             c.AbortWithStatus(204)             return         }          c.Next()     } }

? 使用方式（注册为全局中间件）：

r := gin.Default() r.Use(CORSMiddleware()) // 注册路由... r.Run(":8080")

✅ 关键要点总结：

• ✅ OPTIONS 必须返回 204 No Content，而非 200 OK；
• ✅ Access-Control-Allow-Credentials: “true” 时，Access-Control-Allow-Origin *不可为 ``**，需精确匹配或动态设置；
• ✅ Access-Control-Allow-Headers 应包含前端实际发送的所有自定义头（如 Authorization, X-Requested-With），并补充 accept, origin 等常被忽略的字段；
• ✅ c.AbortWithStatus(204) 后必须紧跟 return，防止执行 c.Next() 导致重复写入响应；
• ⚠️ 生产环境切勿长期使用 * 作为 Origin，应结合白名单或 Origin 校验逻辑提升安全性。

如需更灵活的 CORS 控制（如按路径启用、支持多个 Origin、自动处理 Vary: Origin 头等），推荐直接集成官方维护的 gin-contrib/cors 包，它已完整覆盖 RFC 6454 和现代浏览器行为。