Go 接口 OPTIONS 为什么返回 404：CORS 预检请求的最小处理配方

Go 写接口时，跨域问题经常表现得很绕：浏览器控制台提示 CORS 失败，Network 面板里真正先失败的却是一个 OPTIONS 请求，状态码可能是 404 或 405。这不是前端把方法写错了，而是浏览器在发送真实请求前，先用预检请求确认服务端是否允许这个跨域访问。

直接给结论：如果你的接口允许跨域，并且请求带了自定义请求头、非简单方法或 JSON 提交，Go 服务端需要先正确处理 OPTIONS，返回必要的 CORS 响应头，再让浏览器继续发真实请求。

问题：为什么 GET 没进业务代码，OPTIONS 先 404

典型现场是这样的：前端发起 GET /api/profile，请求里带了 Authorization，浏览器没有马上发送 GET，而是先发一个 OPTIONS /api/profile。如果 Go 后端只注册了 GET 路由，没有任何地方处理 OPTIONS，路由器就可能返回 404。

这一步说明失败发生在“浏览器预检 -> 网关或 Go 路由”之间，还没有进入业务处理函数。先看这条决策路径：

OPTIONS /api/profile HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: GET
Access-Control-Request-Headers: Authorization

HTTP/1.1 404 Not Found

只要预检失败，浏览器就会拦住后续真实请求，所以你在服务端业务日志里看不到 GET，也看不到数据库查询。

最小配方：用 Go 中间件接住预检请求

最小可用做法是写一个 CORS 中间件，先设置允许的来源、方法和请求头，再单独处理 OPTIONS。预检请求不需要进入业务处理函数，通常返回 204 No Content 即可。

func cors(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        origin := r.Header.Get("Origin")
        if origin == "https://app.example.com" {
            w.Header().Set("Access-Control-Allow-Origin", origin)
            w.Header().Set("Vary", "Origin")
        }

        w.Header().Set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
        w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
        w.Header().Set("Access-Control-Max-Age", "600")

        if r.Method == http.MethodOptions {
            w.WriteHeader(http.StatusNoContent)
            return
        }

        next.ServeHTTP(w, r)
    })
}

这里有两个关键点：第一，CORS 响应头要在返回之前写入；第二，遇到 OPTIONS 后要直接返回，不要继续落到只支持 GET 或 POST 的业务路由里。

关键代码：响应头、方法判断和业务路由顺序

把中间件包在最外层，能保证预检请求先被接住。下面是一个标准库 http.ServeMux 的最小服务：

package main

import (
    "encoding/json"
    "net/http"
)

type Profile struct {
    Name string `json:"name"`
}

func profile(w http.ResponseWriter, r *http.Request) {
    if r.Method != http.MethodGet {
        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    _ = json.NewEncoder(w).Encode(Profile{Name: "gopher"})
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/api/profile", profile)

    http.ListenAndServe(":8080", cors(mux))
}

如果中间件放在业务路由后面，或者只给某个 GET 处理函数内部补头，就很容易漏掉 OPTIONS。跨域处理应该靠近入口层，而不是散落在每个接口函数里。

变体：带路由框架和鉴权中间件时怎么放

很多线上服务不是裸用 ServeMux，还会有路由框架、鉴权、日志和限流。推荐顺序是：日志可以最外层，CORS 要放在鉴权之前，业务路由放在最后。

原因很简单：预检请求通常不会携带完整业务凭证，它只是询问“我能不能用这个方法和这些请求头访问”。如果先做鉴权，服务端可能在预检阶段就返回 401，浏览器同样不会继续发送真实请求。

推荐顺序：
request -> access log -> cors -> auth -> router -> handler

不推荐：
request -> auth -> router -> handler 内部临时补 CORS 头

兼容坑：哪些请求会触发预检

不是所有跨域请求都会先发 OPTIONS。常见触发条件包括：

• 方法不是简单方法，例如 PUT、DELETE、PATCH。
• 请求头带了 Authorization、自定义业务头或非简单内容类型。
• Content-Type 是 application/json。
• 前端开启携带凭证时，服务端还要配合明确来源，不能用通配来源。

还有一个常见误区：服务端返回了 Access-Control-Allow-Origin，但漏了 Access-Control-Allow-Headers。浏览器预检时声明了要发 Authorization，服务端却没有允许这个头，结果依然失败。

完整片段：发布前用 curl 反向验证

上线前不要只用页面刷新验证。可以用 curl 模拟浏览器预检，确认状态码和响应头：

curl -i -X OPTIONS 'http://localhost:8080/api/profile' \
  -H 'Origin: https://app.example.com' \
  -H 'Access-Control-Request-Method: GET' \
  -H 'Access-Control-Request-Headers: Authorization'

期望看到类似结果：

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Vary: Origin

再发真实请求，确认业务接口仍然正常：

curl -i 'http://localhost:8080/api/profile' \
  -H 'Origin: https://app.example.com' \
  -H 'Authorization: Bearer demo-token'

总结一下：Go 接口的 CORS 问题不要只盯着真实业务方法。先看浏览器是否发了 OPTIONS，再看服务端有没有在入口层返回 CORS 头和 204。预检通过后，真实 GET 或 POST 才会继续进入业务代码。