Gin框架下同CORS配置不同路径接口跨域失败问题排查

针对你遇到的同前缀接口一个CORS正常、一个报错的情况，核心原因大概率是CORS中间件未正确作用到/api/v1/notion/database路由，或者路由/中间件配置存在细节疏漏，以下是具体排查方向和解决办法：

1. 检查路由与中间件的注册顺序/范围 #

Gin的中间件是链式执行的，若路由注册在中间件生效范围之外，就会导致CORS头无法添加：

• 确认两个接口是否都在同一个应用了CORS中间件的路由Group下，正确的写法应该是先创建Group并绑定中间件，再注册子路由：

  v1Group := router.Group("/api/v1")
  // 给整个v1组应用CORS中间件
  v1Group.Use(cors.New(cors.Config{
      AllowOrigins: []string{"http://localhost:3000"}, // 替换成你的前端实际地址
      AllowMethods: []string{"GET", "POST", "OPTIONS"},
      AllowHeaders: []string{"Content-Type"},
  }))
  {
      v1Group.GET("/notion", yourNotionHandler)
      v1Group.GET("/notion/database", yourDatabaseHandler)
  }
  

• 避免单独注册/api/v1/notion/database且未绑定CORS中间件，或者先注册路由再绑定中间件（这种情况下已注册的路由不会应用后续的中间件）。

2. 排查CORS配置的路径限制 #

如果你的CORS配置中指定了AllowPaths字段，极有可能是没包含子路径：

• 若配置里写了AllowPaths: []string{"/api/v1/notion"}，只会匹配精确路径，不会覆盖/api/v1/notion/database，需要改成通配符形式："/api/v1/notion/*"，或者直接移除AllowPaths字段，让中间件作用于所有路径。

3. 检查接口Handler是否提前返回响应 #

如果/api/v1/notion/database的Handler在中间件设置CORS头之前就返回了响应（比如panic、提前调用c.Abort()或直接写响应后未执行后续中间件），也会导致CORS头缺失：

• 检查Handler代码，确保没有在中间件执行流程完成前强制终止请求；同时确认中间件的注册顺序是在Handler之前（比如不要写成router.GET("/xxx", handler, corsMiddleware)，这种写法会让中间件在Handler之后执行）。

4. 验证预检请求（OPTIONS）的处理 #

如果/api/v1/notion/database的请求触发了浏览器的OPTIONS预检（比如用了非GET/POST方法、带自定义头），后端需要正确响应预检请求：

• 确保CORS配置的AllowMethods包含OPTIONS，cors.Default()默认包含，但自定义配置时要手动添加；
• 用curl模拟预检请求，验证后端是否返回正确的CORS头：

  curl -X OPTIONS http://your-backend-addr/api/v1/notion/database -H "Origin: http://localhost:3000" -v
  

  查看响应头中是否存在Access-Control-Allow-Origin、Access-Control-Allow-Methods等字段。

5. 排查Nuxt3请求的隐性差异 #

虽然你说前端请求仅路径不同，但仍需确认：

• 两个请求的方法是否一致（比如一个是GET，一个是POST）；
• /api/v1/notion/database是否携带了额外的请求头（比如Authorization），导致触发预检；
• Nuxt的代理配置是否对不同路径有差异（比如是否漏代理了/api/v1/notion/database）。

内容的提问来源于stack exchange，提问作者mattia_m