Go微服务跨域Options预检问题解析

Go微服务架构中，跨域OPTIONS预检请求不应由各服务自行处理，而应交由API网关或反向代理（如Nginx、Traefik、Cloudflare）统一承接——开发阶段若前端直连Go服务，则需谨慎配置rs/cors中间件（严格匹配Origin、Headers和Methods，禁用通配符+凭据组合），生产环境则必须剥离服务层CORS逻辑，转由网关集中管控并确保所有潜在路径（包括/、/health等）均被OPTIONS规则覆盖，否则预检将静默失败、日志无痕、调试困难。

Go 微服务本身不该处理跨域预检请求，OPTIONS 请求必须由 API 网关或反向代理统一承接——除非你正本地调试，且前端直连某个 Go 服务。

为什么 Go 服务日志里完全看不到 OPTIONS 请求

常见现象是：前端发 PUT/DELETE 或带 Authorization 头的请求，浏览器卡在 OPTIONS，Network 面板显示 405 或无响应，但 Go 日志里压根没记录任何访问。

• Nginx、Traefik、Cloudflare 等网关默认不转发 OPTIONS 请求；它们可能直接返回 204 或 405，根本不会透传到后端 Go 服务
• net/http.ServeMux 不自动响应 OPTIONS，也没内置预检逻辑；没显式注册或没被中间件覆盖的路径，就按 405 Method Not Allowed 处理
• 即使用了 rs/cors，若它只 wrap 某些子路由（比如只包 /api/），而前端请求的是 /health 或根路径，OPTIONS 仍会掉进默认 405 分支

Nginx 必须显式放行 OPTIONS 才能透传到 Go

别指望 Nginx “自动识别并放行预检”——多数配置下它会直接拦截。重点不是加 CORS 响应头，而是确保请求能抵达 Go 服务（开发期）或被网关自己终结（生产期）。

• 在 location 块中加 if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "*"; add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"; add_header Access-Control-Allow-Headers "Content-Type, Authorization, X-Request-ID"; add_header Access-Control-Allow-Credentials "true"; add_header Access-Control-Max-Age "86400"; add_header Access-Control-Expose-Headers "X-Total-Count"; return 204; }
• 同时确认没有 limit_except 或 deny 规则意外屏蔽了 OPTIONS
• 若用 proxy_pass，确保 proxy_method 未被覆盖，且 proxy_set_header Origin "" 这类清空 Origin 的配置没干扰预检逻辑

本地开发时 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 或 gorilla/handlers.CORS()，不仅冗余，还可能暴露内部服务细节或干扰健康检查路由。

• nginx 生产配置应统一加 add_header Access-Control-Allow-Origin "https://myapp.com" 及对应预检支持
• Traefik 应通过 middlewares 启用 cors 中间件，并绑定到入口点；它会自动响应 OPTIONS，不透传
• Cloudflare 若开启“代理模式”，其边缘节点可能吞掉 OPTIONS；可临时关闭代理，或在规则中显式放行 OPTIONS 方法

最容易被忽略的一点：网关层的路由匹配逻辑是否真的覆盖了所有可能触发预检的路径——比如 /、/health、/metrics，这些看似无关的端点一旦没被 OPTIONS 支持规则捕获，前端发起跨域请求时就会静默失败。

好了，本文到此结束，带大家了解了《Go微服务跨域Options预检问题解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！