net/http 默认不限流，因它仅负责连接处理与路由分发；限流须自行实现，推荐用 golang.org/x/time/rate 基于 IP 或路径构建多键令牌桶中间件，并注意超时控制、错误码透传与指标暴露。
为什么 net/http 默认不限流，而你必须自己加
Go 的 http.Server 本身不提供请求速率限制（rate limiting），它只负责接收连接、解析 HTTP 报文、分发到 handler。高并发下，一个恶意 IP 或突发流量就可能打满 CPU、耗尽 goroutine 或压垮下游服务。限流不是“可选优化”，而是生产环境的兜底防线。
常见误判是用 time.Sleep 或全局计数器硬拦——前者阻塞 goroutine，后者在多实例或高并发下失效。正确做法是使用带滑动窗口或令牌桶语义的中间件，且必须基于每个请求上下文做判断。
用 golang.org/x/time/rate 实现每秒请求数（QPS）限流
rate.Limiter 是 Go 官方维护的轻量级令牌桶实现，适合单机限流。它不依赖外部存储，内存开销低，精度为纳秒级，但注意：它无法跨进程共享状态。
- 初始化时指定
rate.Limit（如10表示每秒 10 个令牌）和桶容量（如5，允许短时突发） - 在 handler 中调用
limiter.AllowN(time.Now(), n)判断是否允许处理n个请求；更常用的是limiter.WaitN(ctx, 1)，自动阻塞等待令牌（适合需保序场景） - 不要对每个请求都新建
rate.Limiter，应按维度（如 IP、API 路径）复用实例，否则 GC 压力大且失去限流意义
func rateLimitMiddleware(limiter *rate.Limiter) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
}
按 IP 或 API 路径做动态限流，避免一刀切
全局限流会误伤正常用户；完全放行又失去意义。实际要区分对待：登录接口可宽松，支付回调必须严格，爬虫 IP 应直接拒绝。
立即学习“go语言免费学习笔记（深入）”；
推荐用 sync.Map + rate.Limiter 构建内存级多键限流器。Key 可以是 r.RemoteAddr（IP）、r.URL.Path 或两者组合。注意：sync.Map 不支持 TTL，需配合定时清理或用 LRU 策略控制 size。
- IP 限流：提取
r.Header.Get("X-Forwarded-For")时需校验可信代理，否则易被伪造 - 路径限流：对
/api/v1/users/:id这类带参数路由，应先正则提取基础路径，避免每个 ID 都生成新限流器 - 避免用
map[string]*rate.Limiter配sync.RWMutex—— 写多读少场景下锁争用严重，sync.Map更合适
生产环境必须考虑的三个边界问题
限流逻辑上线后最常出问题的地方，往往不在算法本身，而在与真实链路的耦合细节。
- 超时控制：若用
WaitN(ctx, 1)，务必传入带 deadline 的context.Context，否则慢限流器会拖住整个请求生命周期 - 错误码透传：Nginx 或 API 网关可能已做一层限流，Go 层返回
429时，前端重试逻辑需识别并退避，不能和500混淆 - 指标暴露：用
prometheus暴露http_requests_total{status="429"}和rate_limiter_tokens_remaining，否则你根本不知道限流是否生效、谁在被拦
跨节点限流（如 Redis + Lua）或更细粒度的请求内容限流（如按 body 大小、特定 query 参数），属于另一层复杂度，单机 rate 包解决不了——别试图在一个包里塞所有需求。
