Golang中实现Web请求限流需选合适算法并结合架构设计。1. 令牌桶（rate.Limiter）适合突发流量，通过rate.NewLimiter(rate.Every(time.Second/100),50)创建每秒100请求、突发50的限流器，在Handler中用Wait或Allow控制；2. 滑动窗口计数器精度高，适用于高并发，可用Redis+Lua原子操作ZSET实现分布式限流，按IP或路径为key存储时间戳；3. 动态配置限流策略，定义Rule结构体从配置中心加载QPS/Burst规则到内存Map，支持定期更新；4. 配套监控上报被拒量、等待时间至Prometheus，超阈值告警并降级处理，结合OpenTelemetry区分429与5xx错误，形成闭环治理。
在Golang中实现Web请求限流，核心是控制单位时间内处理的请求数量，防止服务过载。常用方法包括令牌桶（Token Bucket）、漏桶（Leaky Bucket）和计数器（Fixed Window/Sliding Window），其中令牌桶最灵活，适合突发流量；滑动窗口计数器精度高、内存友好，适合高并发场景。
使用golang.org/x/time/rate实现令牌桶限流
标准库扩展包 rate.Limiter 提供了轻量、线程安全的令牌桶实现，适合大多数HTTP中间件限流需求。
- 创建限流器：例如每秒允许100个请求，最大突发50个——
rate.NewLimiter(rate.Every(time.Second/100), 50) - 在HTTP Handler中调用
limiter.Wait(r.Context())阻塞等待令牌，或用limiter.Allow()非阻塞判断 - 建议搭配
http.TimeoutHandler使用，避免限流等待过久拖垮连接池
基于Redis实现分布式滑动窗口限流
单机限流无法应对多实例部署，需借助Redis+Lua保证原子性。滑动窗口比固定窗口更平滑，能更好应对时间边界突增流量。
- 以用户IP或API路径为key，用Redis ZSET存储时间戳（score）和请求ID（member）
- Lua脚本清理过期时间戳（score window），再统计当前窗口内数量
- 推荐使用 github.com/go-redis/redis/v9 + 自定义中间件，避免每次请求都往返多次
按维度动态配置限流策略
不同用户、接口、来源应有差异化配额。硬编码限流值难以维护，建议结合配置中心或数据库动态加载规则。
立即学习“go语言免费学习笔记（深入）”；
- 定义结构体如
type RateRule { Path string; UserGroup string; QPS int; Burst int } - 启动时加载规则到内存Map，支持定期轮询更新（如每30秒查一次DB或etcd）
- 请求进来后，先匹配规则（如 /api/pay → VIP用户组 → QPS=200），再执行对应限流器
监控与降级：限流不是终点，而是信号
频繁触发限流说明系统承压或配置不合理，需配套可观测能力。
- 记录被拒绝请求数、平均等待时长、各接口命中率，上报Prometheus或日志系统
- 当某接口限流率持续超10%，自动告警并触发降级逻辑（如返回缓存、简化响应）
- 可结合OpenTelemetry打标，区分限流拒绝（429）与业务错误（5xx），便于根因分析
基本上就这些。限流本身不复杂，但容易忽略维度设计、状态同步和反馈闭环。选对算法只是开始，关键在和你的架构、运维习惯、监控体系真正咬合起来。
