用 sync.map 实现 ip 级限流中间件：存 remoteaddr 最近请求时间戳，比对间隔是否小于阈值；注意 x-forwarded-for 校验、避免 redis、统一封装 middleware 而非分散写；rate.limiter 不适合反爬，需结合行为特征识别。
怎么用 Go 实现 IP 级别的请求频率限制
直接上 net/http 中间件最轻量，不依赖第三方库也能做。核心是用 sync.Map 存每个 remoteAddr 的最近请求时间戳，每次进请求时比对间隔是否小于阈值。
常见错误是直接用普通 map + mutex，高并发下锁争用严重；或者用 time.AfterFunc 做自动清理，结果 goroutine 泄漏——sync.Map 自带并发安全，且只存活跃 IP，内存更可控。
- 取
r.RemoteAddr时注意：如果服务在 Nginx 后，得读X-Forwarded-For头，但必须校验来源可信（否则可伪造） - 阈值建议设为 “60 秒内最多 30 次”，太严会误伤 NAT 用户，太松起不到作用
- 别把计数器存 Redis——简单限流没必要引入网络开销，本地内存足够应对万级 QPS
为什么 http.ServeMux 不适合挂限流逻辑
因为 ServeMux 是路径分发器，不提供中间件能力，你没法在路由匹配前统一拦截。一旦写成 func(http.Handler) http.Handler 形式，就必须用自定义 http.Server 或包装 HandlerFunc。
典型踩坑：有人在 HandleFunc 里直接写限流判断，结果每个路由都复制一遍逻辑，改阈值要改七八处；还有人用闭包捕获变量，导致所有路由共享同一组计数器。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是写一个通用封装函数，比如
limitMiddleware(next http.Handler) http.Handler - 然后统一套在
http.ListenAndServe的 handler 上，而不是分散到每个HandleFunc - 如果用了
gorilla/mux或chi，它们原生支持中间件链，优先选它们而非硬啃ServeMux
rate.Limiter 和手写计数器哪个更适合反爬
golang.org/x/time/rate 的 rate.Limiter 适合平滑限流（比如 API 配额），但对反爬意义不大——爬虫通常短连、高频、多 IP 轮换，Limiter 的令牌桶机制无法识别突发扫描行为。
它还会掩盖真实意图：你真正要拦的是“10 秒内来自同一 IP 的 50 次 /login 请求”，而不是“每秒不超过 5 次”。前者是行为模式识别，后者只是速率整形。
-
rate.Limiter的AllowN默认不阻塞，需手动WaitN，一不小心就绕过限制 - 它的
burst参数容易被误解为“允许突增”，实际是桶容量，和爬虫的请求密度无关 - 真要结合行为分析，不如在计数器基础上加字段：记录最近 3 次请求的
URL.Path，发现全为/api/user/\d+就直接拉黑
如何避免把正常用户当爬虫封掉
关键不是“封得多快”，而是“判得多准”。单纯看频率会误杀移动端用户（重试机制多）、企业防火墙（出口 IP 统一）、甚至 Chrome 预加载请求。
最容易被忽略的是 User-Agent 和请求头组合特征：真实浏览器必带 Accept、Sec-Fetch-*，而大多数爬虫（尤其 Requests 库默认）只发最简头。
- 加一层轻量 UA 校验：用
strings.Contains(r.UserAgent(), "Chrome")过滤明显异常值，但别依赖它做主判断 - 记录
Referer是否为空且请求路径为 API —— 正常页面跳转不会出现这种情况 - 给触发限流的 IP 返回
429 Too Many Requests，并在Retry-After头里写明冷却时间，方便前端降级，也避免爬虫盲目重试
复杂点在于：IP 不等于人。一个公司出口、一个校园网、一个手机热点，背后可能是几百个真实用户。所以频率阈值宁可松一点，再靠行为特征补一刀，比一刀切强。
