Go 接口跨域怎么处理：CORS 预检请求、白名单和响应头实战

Go 后端接口用 Postman 调试完全正常，一放到前端页面里跑就报跨域错误，问题基本不在业务 handler 逻辑上，而是卡了浏览器的 CORS 规则：前端页面的域名、请求方法或者自定义请求头触发限制后，浏览器会先自动发一个 OPTIONS 请求，提前跟服务端确认权限。Go 里处理跨域，核心不是随手写一个 * 就完事，而是先识别 Origin、按来源白名单返回正确响应头、妥善处理预检请求，再让真实请求正常进入后续业务逻辑。

为什么浏览器会先发送 OPTIONS 请求

浏览器收到跨源请求时，会先自动校验当前请求符不符合「简单请求」的判定规则。如果请求方法是 PUT、DELETE，或者带了 Authorization、X-Token 这类自定义请求头，就可能先发送一条 OPTIONS 预检请求。

这一步相当于浏览器先跟服务端做一次权限确认：这个来源的请求我接下来要发，你允不允许？用这个请求方法行不行？带这些自定义头有没有问题？如果服务端没有返回符合要求的 CORS 响应头，浏览器直接就把后面的真实请求拦截掉，控制台里只会留下一条跨域报错提示。

用 net/http 实现一个可控的 CORS 中间件

下面这份实现没有多余花哨的逻辑，核心判断逻辑写得很清晰。它只允许白名单里的来源访问接口，预检请求在中间件层直接返回结果，校验通过的真实请求再继续走后面的业务 handler。

package main

import (
    "net/http"
)

func cors(next http.Handler) http.Handler {
    allow := map[string]bool{
        "https://admin.example.com": true,
        "https://www.example.com":   true,
    }

    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        origin := r.Header.Get("Origin")
        if origin != "" && allow[origin] {
            h := w.Header()
            h.Set("Access-Control-Allow-Origin", origin)
            h.Set("Vary", "Origin")
            h.Set("Access-Control-Allow-Methods", "GET,POST,PUT,DELETE,OPTIONS")
            h.Set("Access-Control-Allow-Headers", "Content-Type,Authorization,X-Token")
            h.Set("Access-Control-Max-Age", "600")
        }

        if r.Method == http.MethodOptions {
            w.WriteHeader(http.StatusNoContent)
            return
        }

        next.ServeHTTP(w, r)
    })
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/api/user", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(`{"ok":true}`))
    })

    http.ListenAndServe(":8080", cors(mux))
}

这里有个很容易被忽略的细节：Vary: Origin。如果服务前面还接了缓存层，配置这个头可以提醒缓存系统，同一个接口在不同 Origin 下可能返回不同的跨域响应头，避免把某个来源的响应头错误复用给其他来源，引发跨域异常。

白名单比全开放配置更适合生产环境

开发阶段为了调试图省事，直接返回 * 的做法很常见，但正式上线之后最好收紧权限。尤其是接口需要依赖 cookie、session 或者 Authorization 头做身份校验的时候，跨域规则要和实际业务入口绑定：后台管理域名、前端 H5 域名、内部运营工具域名逐个明确列出来，不要把完全未知的来源也一并放行。

如果需要同时适配多套环境，可以直接把来源白名单放到配置文件里，不用硬编码散落在代码各处：

type CORSConfig struct {
    Origins []string
}

func originSet(list []string) map[string]bool {
    out := make(map[string]bool, len(list))
    for _, item := range list {
        out[item] = true
    }
    return out
}

这个写法逻辑很简单，但后续维护非常方便。测试环境、预发环境、生产环境分别配置对应的允许来源，出问题排查的时候也能直接对照配置确认是不是漏加了对应域名。

预检请求不要走到后续业务链路

预检请求只是浏览器做的权限确认动作，根本不需要触发鉴权失败日志、数据库查询、限流计数扣减或者业务埋点统计。跨域中间件要放在所有中间件的最前面，识别到 OPTIONS 请求之后直接返回结果。

如果查日志的时候发现大量 OPTIONS /api/xxx 401 请求报错，基本都是 CORS 处理逻辑放在了鉴权中间件的后面。调整顺序的时候要按照这个优先级来排：

请求进入 -> CORS 中间件 -> 鉴权中间件 -> 业务 handler

这样浏览器的预检请求先拿到放行结果，后续真实请求再带着认证信息进入各个业务校验流程。排查问题的时候也可以在网关或者 Go 服务的日志里单独统计 OPTIONS 请求的数量，确认有没有出现请求异常放大的情况。

上线前确认这几个细节

第一，如果前端需要跨域携带 cookie，服务端要配置 Access-Control-Allow-Credentials: true，同时 Access-Control-Allow-Origin 不能配置成 *，必须返回前端对应的具体来源。

第二，Access-Control-Allow-Headers 要完整覆盖前端实际会携带的所有请求头。比如前端用了 Authorization 或者 X-Token 自定义头，预检响应里没有对应的放行配置，浏览器依然会拦截请求。

第三，Access-Control-Max-Age 可以减少浏览器重复发送预检请求的次数，但不要设置过大的数值。后续跨域规则调整的时候，浏览器可能还在沿用之前缓存的旧规则，排查问题会多走很多弯路。

相关问题

Go 接口跨域失败，为什么 Postman 能正常请求拿到结果？

CORS 是浏览器独有的安全策略，Postman 不会按照浏览器页面的跨源规则拦截请求。Postman 调用成功只能说明接口本身逻辑可以正常响应，完全不能代表浏览器环境下的跨域响应头配置是正确的。

Access-Control-Allow-Origin 可以一直写星号全开放吗？

完全公开的只读接口可以谨慎使用，但需要登录态的接口、后台内部接口、携带凭证的请求都不推荐这么配置。生产环境更稳妥的方案是按照 Origin 白名单返回请求对应的具体来源。

OPTIONS 请求返回 204 还是 200 状态码？

两个状态码都可以正常工作，行业里更常见的做法是返回 204，代表预检请求不需要返回响应体。核心关注点不要放在状态码的数字上，确认所有 CORS 相关的响应头配置完整才是关键。

明明已经加了跨域响应头，为什么跨域请求还是失败？

直接看浏览器控制台输出的具体报错内容，大概率是漏放了某个请求头、凭证相关的规则不匹配、预检请求被后面的鉴权逻辑拦截了，或者前端反向代理/网关层把你配置的跨域响应头覆盖掉了。优先从浏览器 Network 面板里的 OPTIONS 响应头开始逐层排查。