net/http 默认不处理跨域，因其 http.ServeMux 和 Handler 仅负责基础请求响应，不实现 CORS 规范；需手动添加中间件（如 rs/cors）或在 API 网关层统一配置。
为什么 net/http 默认不处理跨域？
Go 标准库的 http.ServeMux 和 http.Handler 完全不关心 CORS，它只负责转发请求、写响应头、返回状态码。浏览器在发跨域请求（比如前端调用 http://service-a:8080/api，而页面来自 http://localhost:3000）时，会先发一个 OPTIONS 预检请求；如果后端没返回正确的 Access-Control-Allow-Origin 等头，浏览器直接拦截响应，前端 JS 拿不到数据——不是接口没通，是被同源策略“卡”在客户端了。
所以你得自己加中间件，或用现成库补上这些头：
-
Access-Control-Allow-Origin：指定允许哪个源（不能设为*同时带凭证） -
Access-Control-Allow-Methods：列出允许的 HTTP 方法，如GET, POST, PUT, DELETE -
Access-Control-Allow-Headers：声明前端可带哪些自定义请求头（比如Authorization、X-Request-ID） -
Access-Control-Allow-Credentials：设为true时，Access-Control-Allow-Origin不能是*
用 rs/cors 快速启用全局 CORS
社区最常用的是 rs/cors，轻量、无依赖、支持细粒度配置。它本质是个 http.Handler 包装器，套在你的路由外面即可。
安装：go get github.com/rs/cors
基础用法示例：
立即学习“go语言免费学习笔记（深入）”；
import (
"net/http"
"github.com/rs/cors"
)
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/api/users", usersHandler)
// 允许所有源（开发用），但禁止带凭证
handler := cors.Default().Handler(mux)
http.ListenAndServe(":8080", handler)
}
生产环境别用 cors.Default()，应显式控制：
- 用
cors.New(cors.Options{...})替代，明确设置AllowedOrigins（支持通配符如https://*.example.com） - 若需传 cookie 或 token，必须同时设
AllowCredentials: true和AllowedOrigins为具体域名列表 -
ExposedHeaders要填前端 JS 实际需要读取的响应头（如X-Total-Count），否则response.headers.get(...)拿不到
微服务场景下，CORS 应该在哪一层做？
答案是：**在 API 网关层统一做，而不是每个微服务自己加**。否则会出现几个问题：
- 每个服务重复写 CORS 配置，运维难收敛
- 不同服务返回的 CORS 头不一致（比如一个允许
PUT，另一个没开），前端调用行为不可预期 - 服务间内部调用（如 service-a → service-b）也走 CORS 中间件，纯属冗余，还可能误加头影响链路追踪
典型做法：
- 网关（如 Kong、Traefik、或自研 Go 网关）接收所有外部请求，校验 Origin、添加标准 CORS 头、再转发给下游服务
- 微服务内部通信走内网地址（如
http://service-b:8000），不经过网关，也就不触发浏览器 CORS 检查——这部分根本不需要任何 CORS 配置 - 若某服务必须直连（比如调试时绕过网关），才临时启用
rs/cors，上线前删掉
常见错误：预检请求 405 Method Not Allowed
这是最典型的 CORS 故障现象：浏览器发 OPTIONS 请求，后端返回 405，说明你的路由没注册对 OPTIONS 方法。
原因和解法：
-
http.HandleFunc只注册了GET或POST，没覆盖OPTIONS——rs/cors会自动处理预检，但前提是它能接管请求；如果你用的是gorilla/mux或其他路由，确保cors中间件包裹的是最终Handler，而非某个子路由 - 用了
http.ServeMux，但没注册OPTIONS路由，又没挂中间件——此时需手动加：mux.HandleFunc("/api/{path:.*}", optionsHandler)，或改用rs/cors - 某些反向代理（如 Nginx）默认不转发
OPTIONS，检查配置里是否有limit_except或if ($request_method = OPTIONS)之类规则拦截了
CORS 不是黑盒魔法，它只是按规范写几个响应头 + 正确响应预检。真正容易出错的，永远是“谁该写头”和“谁该响应 OPTIONS”。微服务越复杂，越要守住边界：网关管外，服务管内。
