go语言本身不处理跨域，需手动配置cors响应头；常见错误包括options返回404、credentials与*冲突、header设置过晚或遗漏，推荐使用gorilla/handlers.cors中间件统一管理。
Go 语言本身不处理跨域，所有 CORS 行为都由你控制响应头和请求生命周期；用错方式会导致 OPTIONS 404、带 cookie 请求静默失败、或浏览器根本收不到响应——这不是配置“没生效”，是压根没走到浏览器可接受的规范路径上。
手写中间件为什么常返回 404 或静默失败
看似只加几行 w.Header().Set() 就能跑通，但实际运行时极易掉坑里：
-
OPTIONS请求返回 404：因为http.DefaultServeMux对OPTIONS方法无默认路由逻辑，也不会 fallback 到你的 handler，必须显式拦截或由中间件提前响应 -
Access-Control-Allow-Origin: "*"和Access-Control-Allow-Credentials: "true"同时存在 → 浏览器强制丢弃整个响应，Network 面板里连 status 都看不到 - header 设置太晚：在
w.WriteHeader()或首次w.Write()之后调用Set()，完全无效 - 漏设
Access-Control-Allow-Headers：前端发了X-Auth-Token，但后端没声明允许 → 预检直接 403，错误提示明确指出 header 不在白名单中
gorilla/handlers.CORS 是最稳的通用方案
它不依赖框架、轻量无副作用，覆盖所有预检逻辑和 header 设置时机，适合原生 net/http、gorilla/mux 等场景：
- 安装：
go get github.com/gorilla/handlers - 基础用法：
http.ListenAndServe(":8080", handlers.CORS(handlers.AllowedOrigins([]string{"https://myapp.com"}))(r)) -
AllowedOrigins([]string{"*"})时，handlers.AllowCredentials()会被自动禁用——这是对浏览器规范的主动校验，不是 bug - 需要暴露自定义 header（如
X-Request-ID）？加handlers.ExposedHeaders([]string{"X-Request-ID"}) - 动态白名单？改用
handlers.AllowedOriginsFunc(func(origin string) bool { return inWhitelist(origin) })
GIN 用户必须用 gin-contrib/cors，别手写 c.Header()
GIN 的 c.Writer 是封装过的，手写 header 极易绕过中间件链，导致 OPTIONS 响应不全、credentials 冲突或 header 覆盖失效：
- 安装：
go get github.com/gin-contrib/cors - 正确用法：
router.Use(cors.New(cors.Config{AllowOrigins: []string{"https://myapp.com"}, AllowCredentials: true})) - 别在 handler 里写
c.Header("Access-Control-Allow-Origin", "...")—— 它可能在预检阶段未触发，或被后续中间件覆盖 -
AllowOriginFunc优先级高于AllowOrigins，可用于域名校验、子域匹配等复杂逻辑
微服务场景下 CORS 应该在哪一层做
答案是：在 API 网关层统一做，而不是每个微服务自己加。否则会出现几个问题：
- 每个服务重复写 CORS 配置，运维难收敛
- 不同服务返回的 CORS 头不一致（比如一个允许
PUT，另一个没开），前端调用行为不可预期 - 服务间内部调用（如
service-a → service-b）也走 CORS 中间件，纯属冗余，还可能误加 header 影响链路追踪
真正容易被忽略的是：CORS 是浏览器端机制，只对“浏览器发起的跨域请求”有意义；服务间通信走内网、无浏览器参与，加 CORS 头不仅多余，还可能干扰 tracing header 或 proxy 路由逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
