如何在 Gin 框架中正确实现 CORS 中间件-Golang-夏夕资源网-网站模板_免费源码

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

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

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

错误使用 c.AbortWithStatus(200)：虽然返回了 200，但 200 OK 不是预检请求的标准响应状态；RFC 规范要求预检成功应返回 204 No Content（无响应体、语义明确），部分浏览器（尤其是 Chrome 和 Safari）对非标准状态码容忍度低，可能导致预检失败后静默终止流程；
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()
    }
}

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

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

普通

相关推荐

本站指数