微服务中CORS不应在各Go服务内统一处理，而应由反向代理（如nginx、traefik）或API网关统一配置；仅本地开发时才在Go服务中用rs/cors精确指定AllowedOrigins并启用AllowCredentials，避免使用通配符。
Go 微服务中为什么 CORS 不能只靠中间件统一处理
微服务架构下，每个服务独立部署、监听不同端口甚至域名（如 auth.svc:8081、order.svc:8082），前端通常只与网关（如 nginx 或 traefik）通信。真正需要跨域响应头的，其实是网关到前端这一层；后端服务间调用走内网，不触发浏览器同源策略。盲目在每个 Go 微服务里加 gorilla/handlers.CORS()，不仅冗余，还可能暴露内部服务细节或干扰健康检查路由。
应该在哪一层配置 Access-Control-Allow-Origin
绝大多数生产场景下，应由反向代理统一处理 CORS，Go 微服务本身不主动写响应头。例如：
-
nginx配置中添加add_header Access-Control-Allow-Origin "https://myapp.com";和对应预检支持 -
traefik通过middlewares启用cors中间件，并绑定到入口点 - 若使用
API Gateway（如 Kong、Apigee），直接在路由策略中开启 CORS 插件
只有当 Go 服务直接暴露给前端（如本地开发时 localhost:3000 → localhost:8080），才需在服务内启用 CORS —— 此时推荐用 rs/cors（轻量、无依赖）而非 gorilla/handlers（已归档）。
用 rs/cors 做开发期跨域的正确姿势
避免把 * 当万能解：浏览器对带凭证（credentials）的请求禁止使用通配符。必须明确指定源，并开启 AllowCredentials。
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"net/http"
"github.com/rs/cors"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/api/users", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
w.Write([]byte(`{"id": 1}`))
})
// 只允许特定源 + 支持 cookie
handler := cors.New(cors.Options{
AllowedOrigins: []string{"https://myapp.com", "http://localhost:3000"},
AllowCredentials: true,
AllowedMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
AllowedHeaders: []string{"Authorization", "Content-Type", "X-Requested-With"},
}).Handler(mux)
http.ListenAndServe(":8080", handler)
}
注意：OPTIONS 方法无需手动注册路由 —— rs/cors 自动拦截并返回 204；但若自定义了 OPTIONS 处理逻辑，需确保它不覆盖中间件行为。
常见踩坑点：预检失败却没报错
浏览器静默失败（Network 面板显示 canceled 或无响应），大概率是预检（OPTIONS）被防火墙、负载均衡器或中间件提前终止。排查顺序：
- 确认 Go 服务是否收到
OPTIONS请求（加日志或用curl -v -X OPTIONS http://localhost:8080/api/users） - 检查是否遗漏
AllowedHeaders—— 比如前端发了X-Auth-Token，但配置里没包含它 - 确认
AllowedOrigins与请求头Origin完全匹配（协议、域名、端口缺一不可） - 若用 HTTPS 前端访问 HTTP 后端，现代浏览器直接阻止，不发预检请求
微服务内部调用永远不该受 CORS 影响；一旦发现服务间请求因 CORS 报错，说明调用路径错了——不是浏览器发出的，就不可能触发 CORS。
