GCP Kubernetes环境下Go服务http.HandleFunc路由异常问题

看起来你遇到的是典型的路由路径不匹配问题，结合你在GKE集群用Ingress做路由的场景，核心原因大概率是Ingress转发过来的请求路径和你Go服务里注册的路由不对应，导致请求落到了错误的handler上。我来一步步帮你排查和解决：

第一步：先确认请求的实际路径 #

首先你得搞清楚，当用户请求/api/auth/healthz时，最终到达你的Go auth服务的请求路径到底是什么？

你可以在requestHandler里加一行日志，打印请求的路径：

func requestHandler(w http.ResponseWriter, r *http.Request) {
    log.Printf("Received request for path: %s", r.URL.Path)
    // 原有逻辑...
}

部署后再发请求，看日志里的路径是/healthz还是/api/auth/healthz——这是解决问题的关键。

分场景解决 #

场景1：日志显示路径是/api/auth/healthz #

这说明Ingress没有对路径做重写，直接把完整路径转发给了auth服务。而你注册的/healthz路由和这个路径完全不匹配，所以默认ServeMux会把请求交给匹配所有路径的requestHandler（如果它注册在/或者/api/auth/前缀上）。

解决方法有两种：

• 方法A：直接注册完整路径
  把你的路由改成对应完整路径：

  http.HandleFunc("/api/auth/healthz", statusHandler)
  

  这样ServeMux会优先匹配这个更长的路径，请求就会落到statusHandler上。

• 方法B：用路由前缀分组（更推荐）
  如果你的auth服务还有其他/api/auth/xxx的接口，用专门的路由库（比如gorilla/mux）来做前缀分组会更清晰：

  import "github.com/gorilla/mux"
  
  func main() {
      r := mux.NewRouter()
      // 给所有auth接口加前缀/api/auth
      authRouter := r.PathPrefix("/api/auth").Subrouter()
      authRouter.HandleFunc("/healthz", statusHandler)
      // 处理其他/api/auth下的请求
      authRouter.HandleFunc("/", requestHandler)
  
      http.Handle("/", r)
      log.Fatal(http.ListenAndServe(":8080", nil))
  }
  

  这样不管是/api/auth/healthz还是其他/api/auth/xxx的请求，都会被正确路由。

场景2：日志显示路径不是/healthz（但你期望是） #

这说明Ingress的配置有问题，没有把/api/auth/healthz重写为/healthz转发给auth服务。

如果用的是NGINX Ingress（GKE默认常用的），你需要在Ingress的注解里添加路径重写规则：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auth-ingress
  annotations:
    # 关键注解：重写路径，把/api/auth/后的部分作为新路径
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - http:
      paths:
      - path: /api/auth(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: auth-service
            port:
              number: 8080

这样当请求/api/auth/healthz时，Ingress会把路径重写为/healthz转发给auth服务，这时候你原来注册的/healthz路由就能正确匹配了。

额外注意点 #

Go的默认ServeMux是最长前缀匹配，所以路由注册的顺序不影响结果，但如果你的requestHandler注册在/上，它会作为兜底匹配所有未找到的路径——这也是为什么你所有请求都落到它上面的原因。

复杂路由场景下，非常不推荐用默认的ServeMux，gorilla/mux或者chi这类路由库能提供更灵活的匹配规则（比如前缀、正则、参数等），减少这类问题的发生。

内容的提问来源于stack exchange，提问作者Naguib Ihab