Go微服务本身不该处理跨域预检请求，OPTIONS请求应由API网关或反向代理统一承接；常见原因是Nginx等网关默认不转发OPTIONS，直接返回405或204，导致Go服务日志无记录，且net/http.ServeMux不自动响应OPTIONS，需显式配置或使用中间件。
Go微服务本身不该处理跨域预检请求，OPTIONS 请求该由 API 网关或反向代理统一承接——除非你正本地调试，且前端直连某个 Go 服务。
为什么 Go 微服务里收不到 OPTIONS 请求
常见现象是：前端发 PUT/DELETE 或带 Authorization 头的请求，浏览器控制台卡在 OPTIONS，Network 面板显示 405 或无响应，但 Go 日志里压根没打印任何访问记录。
- Nginx、Traefik、Cloudflare 等网关默认不转发 OPTIONS 请求；它们可能直接返回 204 或 405，根本不会把请求透传到后端 Go 服务
- Go 的
net/http.ServeMux不自动响应 OPTIONS，也没内置预检逻辑；没显式注册或没被中间件覆盖的路径，就按 405 处理 - 即使用了
rs/cors，若它只 wrap 某些子路由（比如只包/api/...），而前端请求的是/health或根路径，OPTIONS 仍会掉进默认 405 分支
API 网关层必须显式支持 OPTIONS 转发
别指望网关“自动识别并放行预检”——多数需要手动配置。重点不是加 CORS 头，而是确保 OPTIONS 请求能抵达 Go 服务（开发期）或被网关自己终结（生产期）。
- Nginx：需在
location块中显式允许 OPTIONS，并避免limit_except拦截 - Traefik：用
middlewares启用cors中间件，并绑定到入口点；它会自动响应 OPTIONS，不透传 - Cloudflare：若开启“代理模式”，其边缘节点可能吞掉 OPTIONS；可临时关闭代理，或在规则中放行
OPTIONS方法 - 自研网关：必须检查路由匹配逻辑是否包含
OPTIONS，且不能在鉴权/限流中间件里提前 return
本地开发时，rs/cors 的 Options 配置要点
仅当 Go 服务直连前端（如 http://localhost:3000 → http://localhost:8080）才启用它。此时必须严格校验参数，否则预检仍失败。
-
AllowedOrigins不能写"*"+AllowCredentials: true；必须填具体域名，例如[]string{"http://localhost:3000"} -
AllowedHeaders要和前端实际发送的头一致，比如用了X-Request-ID就得加进去，漏一个就会预检失败 -
AllowedMethods必须包含"OPTIONS"，否则rs/cors不会拦截并响应它 - 不要手动注册
OPTIONS路由——rs/cors会自动处理；若同时写了http.HandleFunc("...", ...)且内部有if r.Method == "OPTIONS"，反而可能冲突
生产环境禁止在 Go 服务内写 CORS 响应头
微服务之间走内网调用，不触发同源策略；真正需要跨域头的，只有网关到前端这一跳。在每个 Go 服务里加 rs/cors 或手写中间件，不仅冗余，还会干扰健康检查、指标采集等内部请求。
- 网关统一加
Access-Control-Allow-Origin等头，Go 服务只管业务逻辑 - 若某服务被意外暴露到公网（比如调试端口未关），它的 CORS 配置可能成为攻击面；网关层隔离更安全
- 不同团队维护的微服务，CORS 策略应由平台组在网关侧统一定制，而非各自为政
最容易被忽略的一点：预检是否成功，不取决于 Go 服务有没有返回数据，而取决于 OPTIONS 请求有没有收到 200/204 + 正确的响应头。哪怕你的 Go 服务完全没启动，只要网关正确响应了 OPTIONS，前端就能继续发主请求。
