go语言本身不处理cors，需服务端按规范返回响应头；硬塞setheader在生产环境易因options预检失败、credentials冲突或header设置时机错误而报错。
Go 语言本身不处理跨域，CORS 是浏览器强制执行的安全策略，服务端只需按规范返回响应头；你在 http.Handler 里硬塞几个 SetHeader 可能跑得通，但生产环境会因 OPTIONS 预检失败、凭证冲突或响应头重复直接报错。
为什么本地开发用 rs/cors 也容易出问题
很多人一上来就 go get github.com/rs/cors，然后照抄示例填 AllowedOrigins: []string{"*"} —— 这在带 credentials: true 的 fetch 请求下必然失败。浏览器看到 Access-Control-Allow-Origin: "*" 和 Access-Control-Allow-Credentials: "true" 同时存在，会直接丢弃响应，控制台只显示模糊的 “CORS error”。
-
rs/cors默认不拦截OPTIONS预检请求（OptionsPassthrough: true），若下游 handler 没配OPTIONS方法，前端发请求前就被 404 卡死 - 开发时用
"http://localhost:3000"硬编码没问题，但一旦加了AllowCredentials: true，就必须把AllowedOrigins改成明确列表，不能留"*" - 如果用了
gorilla/mux，路由没显式声明.Methods("GET", "POST", "OPTIONS")，OPTIONS请求根本不会进中间件，rs/cors彻底失效
手写中间件比第三方库更可控吗
可控，但容易漏关键点。比如只在 next.ServeHTTP 前设 header，却没处理 OPTIONS 返回码，或忘了加 Vary: Origin 导致 CDN 缓存污染。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须检查
r.Header.Get("Origin")是否为空，空值代表非跨域请求，不该设任何 CORS 头 -
OPTIONS响应要立即w.WriteHeader(http.StatusNoContent)或204，不能调用next，否则可能触发业务逻辑副作用 - 若需暴露自定义响应头（如
X-Total-Count），必须显式写w.Header().Set("Access-Control-Expose-Headers", "X-Total-Count")，否则前端response.headers.get()拿不到 - 所有 CORS 相关 header 必须在
WriteHeader之前设置，Go 的http.ResponseWriter一旦写入 body 就无法再改 header
生产环境必须动态校验 Origin 而不是硬编码列表
静态白名单在灰度发布、多租户或临时调试域名（如 https://dev-abc123.ngrok.io）场景下完全不可维护。用 AllowedOriginsFunc 才是正解，但要注意协议和末尾斜杠校验。
- 用
url.Parse(origin)检查 scheme 是否为http或https，拒绝data:、file:等非法协议 -
https://example.com和https://example.com/是两个不同 origin，校验时要去掉末尾斜杠再比对 - 子域名通配（如
"*.example.com"）不被标准支持，得自己用strings.HasSuffix(origin, ".example.com")，但要排除evil.example.com这类恶意构造 - 函数内禁止同步调用外部服务（如 HTTP 请求查配置中心），建议用内存缓存 + 定期刷新，超时控制在 50ms 内
真正难的不是写几行 header，而是理解哪一层该管、哪一层不该管——网关配了 CORS，下游 Go 服务就得彻底关掉；OPTIONS 必须被拦截，不能转发；Vary: Origin 头漏了，CDN 就会把 A 域名的响应缓存后返回给 B 域名，导致跨域失败。这些细节不盯住，线上问题永远复现不了、定位不清。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
