直接用 net/http 的中间件思路在 gin 里会失效，因执行顺序、ip 获取方式（需用 c.clientip() 并标准化）、并发计数安全及过期机制缺失等问题；推荐手写 sync.map + 时间窗口限流或正确配置 gin-contrib/limiter。
为什么直接用 net/http 的中间件思路在 Gin 里会失效
因为 Gin 的中间件执行顺序和请求生命周期与标准库不同，net/http 里靠闭包或全局 map 记录 IP 时间戳的方式，在并发高时容易漏计数或 panic——Gin 的 c.Request.RemoteAddr 可能是代理 IP，且未做端口剥离，直接当 key 用会导致同一 IP 多次被重复计数。
实操建议：
- 始终用
c.ClientIP()替代c.Request.RemoteAddr，它自动处理 X-Forwarded-For 和 X-Real-IP - 对 IP 做标准化：去掉端口号（如
"192.168.1.1:54321"→"192.168.1.1"），可用strings.Split(c.ClientIP(), ":")[0] - 避免用
map[string]int直接存计数——没过期机制，内存只增不减
gin-contrib/limiter 的坑：默认配置根本不限流
这个库默认使用 memory 存储，但它的 Max 是每秒请求数，不是窗口内总数；而且 Expiration 设为 0 时不会自动清理，导致 key 永久残留。
实操建议：
- 显式设置
Expiration: 60 * time.Second，否则计数永不归零 - 把
Max理解成「滑动窗口内允许的最大请求数」，例如设为10+Expiration: 60 * time.Second表示 60 秒内最多 10 次 - 若用 Redis 后端，必须传入非 nil 的
redis.UniversalClient，否则运行时报panic: redis client is nil
简单示例（内存模式）：
import "github.com/gin-contrib/limiter"
<p>r := gin.Default()
r.Use(limiter.New(limiter.Config{
Max: 10,
Expiration: 60 <em> time.Second,
KeyGenerator: func(c </em>gin.Context) string {
return strings.Split(c.ClientIP(), ":")[0]
},
}))
</p>
手写限流中间件：用 sync.Map + 时间窗口更可控
官方库封装太重、配置绕弯，很多场景只需要按分钟统计、返回明确的 429 Too Many Requests 和剩余时间，自己写反而清晰。
关键点：
- 用
sync.Map存map[ip]struct{ count int; last time.Time }，避免锁粒度太大 - 窗口单位用「分钟」比「秒」更实用（防脚本暴力扫端口），key 可设为
ip + ":" + strconv.FormatInt(time.Now().Unix()/60, 10) - 响应头加
X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset，前端调试时一目了然
注意：sync.Map 不支持遍历清理过期项，所以得靠客户端时间戳判断是否窗口已翻页，不能依赖后台定时 goroutine 清理。
真实部署时最常被忽略的两点
一是 Nginx 转发后 X-Forwarded-For 可能被伪造，需在 Nginx 配置中用 set_real_ip_from + real_ip_header X-Forwarded-For 严格限定可信代理段；二是 Kubernetes Ingress 或云 LB 默认不透传原始 IP，得确认 proxy_set_header X-Real-IP $remote_addr 已开启。
如果限流逻辑生效但总看到 127.0.0.1，基本就是这一层没配对。Gin 本身没法解决，得倒查前置网关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
