go http服务收不到options请求是因为默认路由不匹配该方法，需显式注册或统一拦截；预检失败会导致cors错误，正确做法是返回204并设置access-control-allow-origin等响应头。
Go HTTP 服务为什么收不到前端发来的 OPTIONS 请求
因为默认的 http.ServeMux 和大多数中间件（比如 gorilla/mux 的默认配置）根本不会匹配 OPTIONS 方法，除非你显式注册了对应路由。浏览器发起跨域请求前会先发一个不带 body 的预检 OPTIONS 请求，如果服务端没响应，就直接报错 CORS preflight channel failed，连后续的 GET/POST 都不会发。
实操建议：
- 别依赖“自动处理”，Go 没有像 express 那样内置 CORS 中间件
- 要么在每个路由 handler 前加一层统一拦截（推荐），要么为每个需要跨域的路径手动注册
OPTIONShandler - 注意：如果你用的是
net/http原生服务，http.HandleFunc默认只响应GET和HEAD；其他方法需显式检查r.Method
用 net/http 手动处理 Preflight 的最小可行写法
不需要引入第三方库，几行代码就能让预检通过。核心是：响应 204 No Content，带上正确的 Access-Control- 头，且不写 body。
常见错误现象：preflight response doesn't pass access control check: no 'access-control-allow-origin' header 或 header 'x-Token' is not allowed by 'access-control-allow-headers'。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 在主 handler 入口处判断
r.Method == "OPTIONS" - 设置
w.Header().Set("Access-Control-Allow-Origin", "*")（开发可设为*，生产建议明确域名） - 必须设置
Access-Control-Allow-Methods（如"GET, POST, PUT, delete"）和Access-Control-Allow-Headers（如"Content-Type, X-Token"） - 调用
w.WriteHeader(204)后立即 return，不要调用w.Write—— 否则可能触发http: superfluous response.WriteHeader错误
if r.Method == "OPTIONS" { w.Header().Set("Access-Control-Allow-Origin", "*") w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE") w.Header().Set("Access-Control-Allow-Headers", "Content-Type, X-Token") w.WriteHeader(204) return }用 github.com/rs/cors 时为什么 OPTIONS 还是 404
因为 cors.New() 返回的是一个 handler 包装器，但如果你没把它套在最终的 handler 上（比如漏掉了 http.ListenAndServe(":8080", corsHandler)），或者把 cors 放在了路由匹配之后（比如先 router.ServeHTTP 再 wrap），它就完全不生效。
使用场景：适合已有完整路由结构（如 gorilla/mux、chi）的项目，不想改业务逻辑。
实操建议：
-
cors.default()会允许*源、常见方法和头，但不支持凭据（credentials）——需要凭据时必须指定AllowOrigins且不能为* - 确保
cors.Handler(yourRouter)是最外层 handler，不是嵌套在某个子路由里 - 如果用了
gorilla/mux，别在每个router.HandleFunc后单独加cors，而应在最后http.ListenAndServe时统一封装 - 注意：该库默认不处理
OPTIONS路由冲突 —— 如果你已手动注册了/api/users的OPTIONS，它不会覆盖，而是可能被跳过
为什么本地开发 localhost:3000 → localhost:8080 也触发 Preflight
只要协议、域名、端口任一不同，就是跨域。所以 http://localhost:3000 和 http://localhost:8080 端口不同，必然触发预检。这不是 bug，是浏览器强制行为。
性能 / 兼容性影响：Preflight 是额外一次网络往返，延迟明显；某些老旧安卓 webview 可能对 Access-Control-Max-Age 解析异常，导致频繁重复预检。
实操建议：
- 开发时可临时用
Access-Control-Max-Age: "3600"减少重复预检（但别设太大，调试困难） - 避免在
Authorization或自定义头（如X-Request-ID）上过度扩展Access-Control-Allow-Headers，每多一个都可能触发预检 - 如果只是开发联调，更简单的方式是用反向代理（如
nginx或 VS Code Live Server 的 proxy）抹平端口差异，彻底绕过 CORS
实际中最容易被忽略的是：Preflight 响应头必须和后续真实请求的 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 完全匹配，差一个字母、多一个空格，浏览器就拒绝放行。