答案是使用中间件设置响应头并处理预检请求。通过动态设置Access-Control-Allow-Origin、支持OPTIONS方法及配置允许的头和方法，可有效解决Golang服务中的跨域问题，生产环境应避免通配符并维护可信源白名单。
在使用 Golang 构建 HTTP 服务时，前端通过浏览器发起请求经常会遇到跨域问题。这并不是后端语言本身的缺陷，而是浏览器基于安全策略实施的同源限制。要让 Golang 的 HTTP 服务正确响应跨域请求，关键在于设置合适的响应头，并理解预检请求（Preflight）机制。以下是实际开发中常用的处理方式和最佳实践。
理解跨域请求的基本原理
当一个请求的协议、域名或端口与当前页面不一致时，浏览器会认为这是跨域请求。出于安全考虑，浏览器默认阻止前端 JavaScript 接收来自不同源的响应，除非服务器明确允许。
服务器需要在响应头中添加 Access-Control-Allow-Origin 来声明哪些源可以访问资源。例如：
res.Header().Set("Access-Control-Allow-Origin", "https://example.com")如果希望允许多个特定来源，不能直接写多个值，而应根据请求头中的 Origin 动态判断是否在白名单中，再决定返回哪个值。
立即学习“go语言免费学习笔记（深入）”；
处理简单请求与预检请求
并非所有跨域请求都会触发预检。满足以下条件的称为“简单请求”：使用 GET、POST 或 HEAD 方法，且 Content-Type 仅限于 text/plain、multipart/form-data 或 application/x-www-form-urlencoded。
对于非简单请求，比如携带自定义头、使用 PUT/DELETE 方法，或 Content-Type 为 application/json，浏览器会在正式请求前发送一个 OPTIONS 请求进行探测，即预检请求。此时服务器必须正确响应该请求，否则后续请求不会发出。
处理 OPTIONS 请求的关键是返回必要的 CORS 头，常见做法包括：
- 设置 Access-Control-Allow-Methods，声明支持的 HTTP 方法
- 设置 Access-Control-Allow-Headers，列出允许的请求头字段
- 可选设置 Access-Control-Max-Age，缓存预检结果以减少重复请求
使用中间件统一处理跨域
在实际项目中，推荐将 CORS 逻辑封装成中间件，避免每个路由重复编写。以下是一个通用的跨域中间件示例：
func CORSMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { origin := r.Header.Get("Origin") if origin != "" { w.Header().Set("Access-Control-Allow-Origin", origin) w.Header().Set("Access-Control-Allow-Credentials", "true") } if r.Method == "OPTIONS" { w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS") w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization") w.Header().Set("Access-Control-Max-Age", "86400") w.WriteHeader(http.StatusOK) return } next.ServeHTTP(w, r) }) }注册中间件时，将其包裹在路由处理器外层即可生效。例如：
http.Handle("/api/", CORSMiddleware(apiHandler))生产环境注意事项
开发阶段可能直接允许所有来源（Access-Control-Allow-Origin: *），但在生产环境中需谨慎。尤其当启用凭据支持（如 Cookie）时，不能使用通配符，必须指定明确的源，否则浏览器会拒绝请求。
建议的做法是维护一个可信源的白名单，只对匹配的 Origin 返回对应的 Allow-Origin 值。同时记录异常的跨域请求，便于排查潜在的安全风险。
基本上就这些。只要正确设置响应头并妥善处理 OPTIONS 请求，Golang 后端就能平稳应对各类跨域场景，无需依赖第三方库也能实现灵活控制。
