绝大多数团队不该从零写网关，Kong和Traefik已覆盖90%以上生产需求；自研仅适用于深度定制、动态路由或混合协议栈等特定场景，关键在“值不值得”而非“能不能”。
绝大多数团队不该从零写网关——不是技术做不到，而是维护成本远超预期。Kong 和 Traefik 已覆盖 90% 以上生产需求；自研仅在深度定制、动态路由或混合协议栈等特定场景下成立。
要不要自己用 Go 写网关？先看这三点
判断是否该自研，关键不在“能不能”，而在“值不值得”。真实项目里，花两周集成 Kong 插件，比三个月打磨自研网关的熔断降级逻辑更划算。
- Kong 适合强合规场景：需要 JWT 多签发者、OAuth2.0 复杂流程、审计日志留存等
- Traefik 更适合 Kubernetes 环境：靠
IngressRoute+Middleware自动发现服务，配置即代码 - 自研只在以下情况成立：
已有统一认证中心且协议深度定制、灰度流量需按请求头字段做动态路由、或必须嵌入现有gRPC/HTTP/WS混合协议栈
选 gin 还是 gorilla/mux 做路由层？
直接结论：gin 更适合作为网关的 HTTP 入口框架。它不是语法糖多，而是中间件控制流更可靠。
-
gin.Use()和c.Abort()能明确中断后续中间件执行。比如鉴权失败时调用c.AbortWithStatus(401)，后续限流、日志中间件不会触发 -
gorilla/mux的Vars(r)返回map[string]string，类型不安全；而gin的c.Param("id")直接返回string，配合strconv.Atoi更少出错 -
gin默认关闭 debug 模式（GIN_MODE=release），上线不用额外检查环境变量；gorilla/mux无此机制，容易因调试信息泄露路径结构 - 若已有大量
net/http工具函数（如自定义http.RoundTripper），gin的c.Writer就是http.ResponseWriter，无缝接入
httputil.NewSingleHostReverseProxy 的三个必填坑
这个函数是转发基础，但默认行为对生产环境极不友好。不手动覆盖，就会出现 502、跳转到内网地址、X-Real-IP 为空等问题。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 必须重写
Director字段：设置req.Host = upstream.Host，并补充req.Header.Set("X-Real-IP", getClientIP(r)) - 响应头中的
Location必须重写为公网域名，否则前端会重定向到http://user-srv:8081/login这类地址 - 每次
proxy.ServeHTTP(w, r)后，要在defer中调用cancel()并检查ctx.Err()，否则上游 hang 住会导致连接泄漏
http.Transport 配置错一个字段，网关就成故障放大器
网关转发不是把 http.DefaultTransport 一贴了事。默认 Transport 在后端抖动时会卡死、耗尽 fd、误判超时。
-
Timeout控制整次请求生命周期，建议设为 5–8 秒（比下游 P99 高 2 秒），太短误杀正常请求，太长拖垮并发 -
IdleConnTimeout推荐 30 秒，和大多数后端 HTTP server 的 keep-alive timeout 对齐 -
MaxIdleConnsPerHost必须显式设置（如 100），避免文件描述符耗尽；别碰TLSClientConfig.InsecureSkipVerify，那是测试用的，上线必须删 - 重试逻辑不要塞进
Transport，用独立中间件做：只对502/503/504和连接级错误（net.ErrClosed、context.DeadlineExceeded）重试 1 次，且带 jitter
真正难的不是写转发逻辑，而是让每一次 proxy.ServeHTTP 都可控、可退、可追溯——时间同步偏差、连接泄漏、Transport 参数错位，任何一个点没压住，都会在高并发下突然放大成雪崩。
