令牌桶更适合Python Web接口，因其支持突发流量、配置灵活、Redis实现简单；漏桶易误限流且分布式下精度难保障。
令牌桶和漏桶，哪个更适合 Python Web 接口
令牌桶更灵活、更常用，尤其适合突发流量场景；漏桶严格匀速，容易在真实业务中造成误限流。Python 生态里 slowapi、fastapi-limiter 默认都用令牌桶，不是偶然。
原因很简单：Web 接口常有短时峰值（比如秒杀开场、定时任务触发），漏桶会把本可处理的请求直接挡掉；而令牌桶允许“借”几个令牌先扛住，只要后续填得上，就不伤体验。
-
token_bucket的capacity和refill_rate可调，能适配不同接口的容忍度（比如登录接口严一点，查询接口松一点） - 漏桶的
leak_rate一旦设死，就难兼顾“快响应”和“防刷”，改一次要全量重启 - Redis 实现漏桶需额外维护“上次漏水时间”，精度依赖系统时钟，分布式下易出错；令牌桶只需原子增减一个计数器，
INCRBY+EXPIRE就够
用 redis-py 手写限流时，eval 脚本为什么不能少
不加 Lua 脚本，GET + INCR + EXPIRE 三步操作在并发下会失效——多个请求同时读到 0，又各自 INCR 成 1，结果放行了 5 个本该被限的请求。
必须用 eval 把判断和更新包成原子操作。别信“我只用单线程 Flask 就没事”，HTTP 服务器（如 Uvicorn）默认开多 worker，Redis 连接是共享的。
立即学习“Python免费学习笔记（深入）”；
- 脚本里要用
redis.call("INCR", key)而不是redis.call("GET", key)再INCR，否则还是有竞态 - 记得
EXPIRE放在INCR后面，且只对新 key 生效（if ttl == -1 then redis.call("EXPIRE", key, expire_s) end） - 返回值建议设计成：-1 表示拒绝，>=0 表示剩余令牌数，方便前端做降级提示
fastapi-limiter 的 key_func 写错会导致全局限流
默认 key_func 是按路径限流，所有用户共用一个桶。你要按用户限流，却忘了重写这个函数，结果 A 用户刷爆了，B 用户跟着 429 —— 这不是 bug，是配置没到位。
常见错误写法：key_func=lambda request: request.url.path，看起来没错，但漏掉了身份标识。
- 需要从
request提取唯一标识：JWT 用request.state.user_id（前提是中间件已解析并挂载），Session 用request.cookies.get("session_id") - 注意空值处理：匿名用户建议用
request.client.host+request.headers.get("user-agent")拼接，避免空字符串导致 key 冲突 - 如果用了
Depends注入依赖，key_func里不能直接调用依赖函数，得提前在路由层 resolve 好再传进去
内存限流（ratelimit 库）在生产环境为什么不敢用
因为它是基于 threading.local 或全局 dict 实现的，每个进程一份状态。Uvicorn 开 4 个 worker，同一 IP 的请求打到不同进程，限流就形同虚设。
除非你确定永远只跑单进程（比如本地调试、CLI 工具），否则别在 Web 服务里用 ratelimit 或 limits 的内存后端。
- 查文档会发现它支持 Redis，但默认不启用——必须显式传
storage="redis://..."，且版本 >= 2.0 - 旧项目若混用
limits1.x 和 Redis，可能因序列化方式不一致导致 key 解析失败，报ValueError: not enough values to unpack - 内存限流唯一靠谱的场景：异步任务内部的子调用节流（比如 Celery 里限制调第三方 API 的频率），此时单进程上下文可控
真正麻烦的从来不是选算法，而是怎么让 key 既唯一又安全、怎么让 Redis 调用不拖慢主流程、还有——当运维说“限流开关要能热更新”，你得想清楚配置项到底该放 etcd 还是 Redis Hash。
