使用Golang实现简单的反爬虫策略_Web访问频率分析

用 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 不等于人。一个公司出口、一个校园网、一个手机热点，背后可能是几百个真实用户。所以频率阈值宁可松一点，再靠行为特征补一刀，比一刀切强。