Go HTTP服务默认不处理CORS，需手动添加中间件或响应头；常见错误包括OPTIONS 404、凭证请求被拦、Nginx透传失败；推荐用gorilla/handlers或gin-contrib/cors，注意origin与credentials互斥、header设置时机及Nginx透传配置。
Go HTTP服务默认不处理CORS，必须手动加中间件或响应头
Go 的 net/http 包本身完全不管跨域，浏览器报 Access-Control-Allow-Origin 缺失、预检请求 404 或被拦截，都是因为后端压根没回对应 header。不是框架“不支持”，是 Go 原生就“不掺和”——你得自己写，或者用轻量中间件补上。
常见错误现象：OPTIONS 请求返回 404；带 Authorization 头的请求被拦；前端拿到数据但控制台持续报 CORS 错误；本地 localhost:3000 调 localhost:8080 成功，部署到 Nginx 后失败（其实是 Nginx 没透传 header）。
- 最简做法：在 handler 开头统一写
w.Header().Set("Access-Control-Allow-Origin", "*")，仅适用于无凭证（credentials）的公开接口 - 若需携带 cookie 或认证头，必须指定具体域名（不能用
*），且要加w.Header().Set("Access-Control-Allow-Credentials", "true") - 预检请求（
OPTIONS）必须显式响应，不能只靠DefaultServeMux自动 fallback；建议用http.HandlerFunc显式注册或用中间件拦截 - 注意 header 设置顺序：必须在
w.WriteHeader()或首次w.Write()之前调用，否则无效
用 gorilla/handlers 中间件是最稳的生产方案
手写 header 容易漏字段、难覆盖预检逻辑、不兼容复杂场景（比如动态 origin 白名单）。gorilla/handlers 是社区事实标准，轻量、无依赖、更新勤，比自己 roll 一个更可靠。
使用场景：需要支持 credentials、自定义允许方法、暴露特定 header（如 X-Request-ID）、按 path 分级配置 CORS。
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go get -u github.com/gorilla/handlers - 基础用法：
http.ListenAndServe(":8080", handlers.CORS(handlers.AllowedOrigins([]string{"https://example.com"}))(r)) - 常见组合参数：
handlers.AllowedMethods([]string{"GET", "POST", "PUT", "DELETE"})、handlers.ExposedHeaders([]string{"X-Total-Count"})、handlers.MaxAge(3600) - 注意：
AllowedOrigins若传["*"]，则自动禁用AllowCredentials；二者不可共存，这是浏览器规范强制的
GIN 框架里别直接改 ResponseWriter，要用 Use() 注册中间件
GIN 用户常犯的错：在某个路由 handler 里写 c.Writer.Header().Set(...)，结果预检失败或 header 重复。GIN 的 c.Writer 是封装过的，部分操作（尤其 OPTIONS 响应）必须走中间件链路才完整生效。
性能影响：CORS 中间件是纯 header 注入，无 IO、无计算，对 QPS 几乎零影响；但若在中间件里做 origin 白名单查库或 Redis，就会拖慢所有请求。
- 正确姿势：
r.Use(cors.New(cors.Config{AllowOrigins: []string{"https://myapp.com"}}))（用官方github.com/gin-contrib/cors） - 不要在 handler 内部用
c.Header()覆盖已设置的 CORS header，GIN 中间件默认会在写响应前 final render 一次 - 调试技巧：用
curl -I -X OPTIONS http://localhost:8080/api/foo看响应头是否含Access-Control-Allow-Methods，而不是只测 GET - 若用自定义中间件，务必检查是否对
OPTIONS方法提前c.Abort()并c.Status(204)，否则可能走到后续 handler 报 404
Nginx 前置时，Go 服务的 CORS header 可能被覆盖或丢弃
很多团队把 Go 服务挂 Nginx 后，突然 CORS 失效。不是 Go 写错了，是 Nginx 默认不透传自定义 header，尤其以 Access-Control- 开头的，还可能缓存了 preflight 响应。
典型表现：本地直连 Go 服务正常，Nginx 反代后 OPTIONS 返回 200 但没 CORS header；或第一次请求 OK，第二次报错（因 Nginx 缓存了 preflight 结果）。
- Nginx 配置关键项：
add_header Access-Control-Allow-Origin "$http_origin" always;（always确保 204/4xx 也带） - 必须显式放行预检 header：
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";、add_header Access-Control-Allow-Headers "Content-Type, Authorization"; - 禁用 preflight 缓存：
add_header Access-Control-Max-Age "3600";+ 在 location 块加if ($request_method = 'OPTIONS') { add_header Access-Control-Max-Age 1728000; } - 最保险的做法：Nginx 只负责透传，CORS 全由 Go 服务输出；此时需在 Nginx 关掉所有
add_headerCORS 相关项，并确认proxy_pass后的 Go 服务确实返回了完整 header
跨域问题真正复杂的地方不在 Go 代码怎么写，而在于你永远得同时盯住三处：Go handler 的 header 输出时机、反代层（Nginx / Cloudflare）是否透传、前端 fetch 是否带 credentials: "include" 却配了通配 origin。少验一处，就白调半小时。
