本文详解 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()
}
}? 使用方式（注册为全局中间件）：
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 和现代浏览器行为。
