ThinkPHP 本身不内置令牌桶，必须用 Redis::eval 执行 Lua 脚本原子实现，否则高并发下必超发；核心是 tokens 与 last_fill_time 双状态更新、补令牌计算及判断必须在单次 Lua 调用中完成，禁止 GET+DECR 拆分操作。
ThinkPHP 中用 Redis 实现令牌桶限流的关键逻辑
直接说结论：ThinkPHP 本身不内置令牌桶，必须自己用 Redis::eval 或原子操作组合实现，否则在并发下会漏桶或超发。核心在于「获取令牌」这一步不能拆成 GET + DECR 两步，得用 Lua 脚本保证原子性。
为什么不能只用 redis->decr() 判断剩余数
常见错误是先 get 当前令牌数，再 decr，中间可能被其他请求插队，导致超发。尤其在高并发时，decr 返回负数也不代表“没令牌了”，因为没同步更新时间戳和重置逻辑。
- 令牌桶需同时维护两个状态：
tokens（当前令牌数）和last_fill_time（上次填充时间） - 每次请求要先算出应补充多少令牌：
min(capacity, tokens + (now - last_fill_time) * rate) - 这个计算 + 更新必须在一个 Lua 脚本里完成，否则 race condition 不可避免
一个可用的 ThinkPHP + Redis 令牌桶 Lua 脚本封装
把 Lua 脚本写进 app/common/behavior/RateLimit.php 或单独工具类里，调用时传入 key、容量、速率（token/s）、过期时间：
// Lua 脚本内容（注意：换行和空格会影响 SHA1，建议存为字符串常量）
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])
local expire = tonumber(ARGV[3])
local now = tonumber(ARGV[4])
<p>local tokens_key = key .. ':tokens'
local time_key = key .. ':time'</p><p>local tokens = tonumber(redis.call('GET', tokens_key) or capacity)
local last_fill = tonumber(redis.call('GET', time_key) or now)</p><p>local delta = math.max(0, now - last_fill)
local fill = math.floor(delta * rate)
local new_tokens = math.min(capacity, tokens + fill)</p><p>local allowed = 0
if new_tokens > 0 then
new_tokens = new_tokens - 1
allowed = 1
end</p><p>redis.call('SET', tokens_key, new_tokens)
redis.call('SET', time_key, now)
redis.call('EXPIRE', tokens_key, expire)
redis.call('EXPIRE', time_key, expire)</p><p>return {allowed, new_tokens}</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill11046" title="Sentinal Redis"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Sentinal Redis" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill11046" title="Sentinal Redis">Sentinal Redis</a>
<p>监控Redis服务器健康状况、内存、性能及BullMQ队列。检查队列深度、失败任务，分析慢查询并诊断问题。</p>
</div>
<a href="/xiazai/skill11046" title="Sentinal Redis" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p><span>立即学习</span>“<a href="https://pan.quark.cn/s/7fc7563c4182" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">PHP免费学习笔记（深入）</a>”；</p>在控制器中调用：
$redis = \think\facade\Cache::store('redis')->handler();
$key = 'rate:api:' . $request->ip();
$capacity = 10;
$rate = 2; // 每秒补 2 个
$expire = 60;
<p>$result = $redis->eval($luaScript, [$key], [$capacity, $rate, $expire, time()]);
list($allowed, $left) = $result;</p><p>if (!$allowed) {
throw new HttpException(429, 'Too Many Requests');
}</p>实际部署时容易忽略的三个点
很多人跑通了单机脚本就以为 OK，但上线后仍会超限或误拦截：
-
time()在多台服务器上不同步 —— 必须统一用microtime(true)或 NTP 校准，不能依赖各机器本地时间 - Redis 连接未设置
read_timeout和retry_interval，网络抖动时脚本执行失败，但业务没兜底，直接放行 - key 设计没带用户/接口维度，比如用
rate:api全局一把锁，导致一个用户刷崩整个接口；应至少含$request->routeInfo()['rule']或$request->header('X-Real-IP')
令牌桶真正的复杂点不在算法本身，而在时间精度、分布式一致性、以及失败路径是否真正阻断请求。Lua 脚本只是起点，后续还得加监控看 allowed 返回分布、定期清理过期 key、考虑突发流量时的预热策略。
