核心是控住连接、超时、上下文和路由性能：需显式配置http.Transport（MaxIdleConnsPerHost、IdleConnTimeout、MaxIdleConns）、DNS超时，复用Client与URL模板，用radix树路由而非正则，分层context超时并严格cancel，按业务域分组中间件且鉴权失败立即返回。
用 Echo 框架写生产级 API 网关，核心不是“能不能跑”，而是能不能控住连接、超时、上下文和路由性能——否则流量一上来，http.Transport 耗尽 fd、context 泄漏、url.Parse 重复解析、正则路由线性扫描，四个坑一起爆。
怎么避免 http.Transport 被打穿
默认的 http.DefaultTransport 对高并发转发极其危险：空闲连接不回收、最大连接数不限、DNS 解析没超时。网关每秒处理 2000 请求时，若每个后端服务没配连接池，fd 很快到 65535 上限，报错 dial tcp: lookup xxx: no such host 或 too many open files。
- 必须显式构造
http.Transport，设MaxIdleConnsPerHost: 100、IdleConnTimeout: 30 * time.Second、MaxIdleConns: 1000 - DNS 解析要单独控超时：
&net.Dialer{Timeout: 2 * time.Second, KeepAlive: 30 * time.Second}传给Transport.DialContext - 别在每次请求里 new 一个
http.Client；复用单例 client，transport 复用更关键 - 转发前用
url.URL.ResolveReference拼地址，而不是每次url.Parse—— 后者分配内存且慢
路由匹配为什么不能用 echo.Any() 或正则
网关路由表通常上百条，如果用 e.Any("/*", proxyHandler) 或手写 regexp.MustCompile 匹配路径，会退化成 O(n) 线性扫描，CPU 直接卡在字符串比较上。实测 500 条正则路由下，P99 延迟从 3ms 涨到 47ms。
- 必须用 Echo 内置的 radix 树能力：
e.GET("/api/v1/users/:id", ...)、e.POST("/v1/models/:model/invoke", ...) - 通配符
:id和*是安全的，底层已优化为前缀树跳转；但e.Use(middleware.RateLimiter(...))不能套在Any上，会误限健康检查等静态路径 - 动态服务发现场景下，别把
url.Parse("http://"+svcAddr+"/path")放进 handler；提前 parse 模板 URL，运行时只做ResolveReference - 需要 Host 分路由？用
e.Host("api.example.com").Group(...)，它底层是 map 查找，非正则
context.Context 怎么透传才不泄漏
中间件链里随便 ctx, cancel := context.WithTimeout(ctx, 5*time.Second) 却不 defer cancel()，是网关 goroutine 泄漏头号原因。尤其在鉴权失败短路、熔断器触发跳过后续插件时，cancel 调用极易遗漏。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
立即学习“go语言免费学习笔记（深入）”；
- 所有超时必须分层：网关总耗时 timeout（如 8s） ≠ 后端转发 timeout（如 10s），后者要多留 buffer 防调度延迟
- 转发请求必须用
http.NewRequestWithContext(childCtx, req.Method, req.URL.String(), req.Body)，而非改原req.Context() - 客户端主动断连（返回
499 client closed request）时，要立刻cancel()对应后端请求 context，否则 goroutine 卡在RoundTrip - 传用户 ID、traceID 这类数据，定义强类型 key：
type userIDKey string; const userIDKey = "user_id"，避免c.Set("user_id", id)这种字符串硬编码
中间件顺序和短路逻辑怎么组织
把 JWTAuth、RateLimiter、Logger 全堆在 e.Use() 里，看似方便，实际一出 panic 就全崩，且鉴权失败还继续走限流、日志，浪费资源又难定位问题点。
- 按业务域分组挂中间件：
userAPI := e.Group("/api/v1/users"); userAPI.Use(authMw, rateLimitMw)，别全塞顶层 - 鉴权中间件必须返回
c.NoContent(401)或c.JSON(401, ...)并return，不能只写c.Error(...)就往下走 - 日志中间件里别读
c.Request().Body—— 它是一次性 reader，业务 handler 会拿不到数据；要用httputil.DumpRequest(c.Request(), false) - 压缩中间件（如
middleware.Gzip()）必须放在最后，否则Content-Encoding: gzip响应体被后续中间件误解析
真正卡住上线的，从来不是 echo.New() 或几行路由注册，而是 transport 连接池没调、context 没 cancel、URL 每次 parse、错误中间件不 return —— 这些细节不抠，压测时根本看不出问题，上线后突发流量才暴露。
