直接选 gin-gonic/gin——它默认支持中间件链、路径参数提取快、内存占用低，高并发下比 gorilla/mux qps 高 15%～20%，尤其嵌套路由场景更优，且具备稳定路径获取和便捷适配能力。
用 gorilla/mux 还是 gin-gonic/gin 做路由层？
直接选 gin-gonic/gin——它默认支持中间件链、路径参数提取快、内存占用低，而 gorilla/mux 在高并发下路由匹配慢一截，且原生不带限流/鉴权钩子。
真实压测中，相同路由规则下 gin 的 QPS 高出 15%～20%，尤其在嵌套路由（如 /api/v1/users/:id/orders）场景更明显。
别被 “gorilla 更标准” 误导：网关不是 Web 框架比拼，而是吞吐、可控性和可维护性的平衡。
-
gin的c.Request.URL.Path和c.FullPath()能稳定拿到原始路径，适合做前置路由分发；gorilla/mux的Vars在嵌套中间件里容易丢上下文 - 如果你已有
net/http服务要复用，用gin的gin.WrapF()包一层就行，不用重写 handler 签名 - 别自己实现 path prefix match：用
router.Group("/api")+Use()，否则路径截断逻辑容易漏掉//或 trailing slash 变体
net/http.RoundTripper 自定义超时和连接复用的关键点
网关转发不是简单 http.DefaultClient.Do() ——默认的 http.Transport 在长连接复用、空闲连接清理、DNS 缓存上都不够细粒度，容易在流量突增时打满后端连接数或卡死在 DNS 查询上。
- 必须显式设置
MaxIdleConns和MaxIdleConnsPerHost，建议都设为100起步，否则默认2会成为瓶颈 -
IdleConnTimeout设成30s，太短导致频繁建连，太长会让故障节点残留连接更久 - DNS 缓存必须接管：
&net.Resolver{PreferGo: true, Dial: dialContext}+ 自定义dialContext实现 TTL 控制，否则系统 DNS 缓存可能长达 5 分钟 - 转发前记得清空
req.Header中的Connection、Keep-Alive等 hop-by-hop 字段，否则后端可能拒收
限流用 golang.org/x/time/rate 还是 uber-go/ratelimit？
用 golang.org/x/time/rate 就够了，但必须注意它的 Limiter 是 *per instance*，不是全局共享——直接 new 出来塞进 handler 会导致每个请求都拿新限流器，完全失效。
- 按 key（比如
user_id或ip）做限流，得自己用sync.Map缓存*rate.Limiter，key 过期用time.AfterFunc清理，别依赖 GC -
rate.NewLimiter(rate.Every(time.Second), 10)表示“每秒最多 10 次”，但突发流量下会允许最多 10 次瞬时通过（burst 容量），别误以为是严格匀速 - 别在限流中间件里用
time.Sleep等待——这会阻塞 goroutine；要用limiter.Wait(ctx)，配合超时 context 提前返回429 - 如果需分布式限流（跨多台网关实例），
rate.Limiter不适用，得切到 Redis + Lua（如redis-cell）或专用服务，本地限流只解决单机毛刺
JWT 鉴权中间件里最容易漏掉的三个检查
很多实现只校验签名和过期时间，但攻击者早就能绕过这些基础检查。
- 必须验证
iss（issuer）字段是否匹配你签发方的固定域名，否则任意 JWT 服务签的 token 都能过 -
aud（audience）字段要明确限定为当前网关识别的 service name，比如"user-api"，避免 token 被滥用于其他内部服务 - 别忽略
nbf（not before）时间戳，某些恶意生成的 token 会把nbf设在未来，导致“尚未生效却已接受”的逻辑漏洞 - 公钥轮换时，别硬编码 PEM 字符串——从文件或远程配置中心加载，并监听变更事件重载
*jwt.SigningKey，否则重启才能生效
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
