Golang实现API网关路由与转发方法

够，但仅适用于轻量静态路由；不支持动态路由、健康检查、超时重试、熔断、JWT鉴权或限流，无法满足多后端、灰度发布、热更新等生产网关需求。

用 gorilla/mux 做基础路由转发够不够？

够，但只适用于轻量、静态路由场景。它不支持动态增删路由、无健康检查、不处理超时/重试/熔断，也不自带 JWT 验证或限流能力。如果你的网关要对接多个后端服务、需灰度发布或运行时热更新路由规则，gorilla/mux 就只是个起点，不是终点。

常见错误是直接拿它当生产网关用，结果发现无法根据请求头做路由、不能按权重分发、日志里连哪个后端挂了都查不到。

• 路由必须硬编码在启动时注册，改一条就得重启服务
• 没有内置反向代理逻辑，得自己调 httputil.NewSingleHostReverseProxy 拼接
• 所有中间件（鉴权、日志、指标）都要手动 wrap，容易漏掉 return 或 panic 捕获

如何用 net/http + httputil.NewSingleHostReverseProxy 实现可配置转发？

这是 Golang 官方推荐的轻量反向代理方案，适合自研网关的核心转发层。关键点不在“怎么转”，而在“怎么安全地转”——比如 Host 头透传、URL 路径截断、后端健康状态感知。

下面是最小可用示例，重点看三处：Director 改写请求、ModifyResponse 改写响应、ErrorHandler 捕获连接失败：

func NewReverseProxy(backendURL *url.URL) *httputil.ReverseProxy {
    proxy := httputil.NewSingleHostReverseProxy(backendURL)
    proxy.Director = func(req *http.Request) {
        req.URL.Scheme = backendURL.Scheme
        req.URL.Host = backendURL.Host
        // 截掉前缀 /api/v1，再拼到后端路径上
        req.URL.Path = strings.TrimPrefix(req.URL.Path, "/api/v1")
        req.Header.Set("X-Forwarded-For", clientIP(req))
    }
    proxy.ModifyResponse = func(resp *http.Response) error {
        resp.Header.Set("X-Powered-By", "go-gateway")
        return nil
    }
    proxy.ErrorHandler = func(rw http.ResponseWriter, req *http.Request, err error) {
        log.Printf("proxy error to %s: %v", backendURL, err)
        http.Error(rw, "upstream failed", http.StatusServiceUnavailable)
    }
    return proxy
}

• req.URL.Path 必须显式截断，否则会把原始路径（如 /api/v1/users）原样发给后端，而它可能只认 /users
• 不设 ErrorHandler 时，连接超时或拒绝会直接 panic，导致整个网关进程 crash
• Director 中不要修改 req.Host，除非后端明确依赖该 header；多数情况应让 req.URL.Host 决定实际连接目标

路由匹配为什么不能只靠 PathPrefix？

因为真实 API 网关要处理多种匹配维度：路径前缀、方法、Host、Header、Query 参数甚至 JWT claim。只靠 PathPrefix 会撞上两个硬伤：无法区分 GET /users 和 POST /users，也无法实现 host-based routing（比如 admin.example.com → 用户管理后台）。

正确做法是把路由规则抽象成结构体，运行时加载并逐条匹配：

type Route struct {
    ID        string   `json:"id"`
    Match     Match    `json:"match"`
    Backend   string   `json:"backend"`
    StripPath string   `json:"strip_path"` // 如 "/api"
}
type Match struct {
    Path    string            `json:"path"`    // 支持正则，如 "^/v1/.*"
    Method  []string          `json:"method"`  // ["GET", "HEAD"]
    Headers map[string]string `json:"headers"` // {"X-Api-Version": "2"}
}

• 用 regexp.Compile 编译路径正则，避免每次请求都重复编译
• Match.Method 必须严格比对，忽略大小写会导致安全绕过（如 get 绕过 GET 规则）
• Header 匹配建议用 strings.EqualFold，但值匹配必须全等，不能 substring

为什么别急着集成 traefik 或 nginx？

因为它们解决的是通用问题，而你的业务网关往往有定制需求：比如需要从 Redis 动态拉取路由、在转发前调用内部风控服务、把 traceID 注入到 gRPC metadata。硬套现成网关反而要写一堆插件或 patch，维护成本更高。

真正该评估的是：是否已有团队熟悉其配置语法？是否需要 TLS 终止、Websocket 支持、mTLS？有没有现成的监控埋点？如果答案大多是“否”，那用 Golang 自研一个精简版（500 行以内核心逻辑），配合 etcd 存储路由规则，反而上线更快、问题更可控。

最容易被忽略的一点：无论用什么方案，context.WithTimeout 必须作用于每个后端请求，且超时时间要明显短于客户端请求超时（比如客户端设 30s，后端转发设 25s），否则会堆积 goroutine 直至 OOM。