不能只用 INCR + EXPIRE 手动配对，因PHP进程不共享内存，两命令间存在竞态窗口，可能导致key永久驻留或EXPIRE失败而不过期；必须用Lua脚本原子执行计数、过期与阈值判断。
为什么不能只用 INCR + EXPIRE 手动配对
因为 PHP 进程之间不共享内存，INCR 返回 1 后立刻调 EXPIRE 看似合理，但两个 Redis 命令之间存在微小时间窗口——并发请求可能同时看到 key 不存在、同时 INCR 成功、同时跳过 EXPIRE，结果 key 永久驻留。更糟的是，如果某次 EXPIRE 失败（网络抖动、Redis 临时不可用），这个 key 就再也不会过期。
真实线上事故里，90% 的 Redis 内存爆满都源于这类“漏掉过期”的 key。必须用 Lua 脚本把计数、过期、阈值判断三步锁死在一次原子操作里。
令牌桶限流的 Redis 键设计与时间补算逻辑
令牌桶不是简单计数，它要模拟「随时间恢复」的行为：每个 key 需存两个字段：rate:api:{identifier}:tokens（剩余令牌）、rate:api:{identifier}:ts（上次更新时间）。每次请求进来，先读这两个值，再按公式补令牌：min(max_tokens, current_tokens + (now - last_ts) * rate_per_second)。
关键点：
立即学习“PHP免费学习笔记（深入）”；
- 补完令牌后必须立刻扣 1，再写回 Redis；否则并发请求会重复补、重复扣，导致超发
- 必须用
GETSET或 EVAL 脚本保证「读-算-写」不被中断，PHP 层不能做条件判断后再写 - rate_per_second 别设太高（比如每秒 100 个），否则
now - last_ts稍大就会直接补满，失去限流意义
如何安全提取用户标识避免被绕过
$_SERVER['REMOTE_ADDR'] 在有 Nginx、CDN 或云 WAF 时几乎必然失效——你拿到的是内网 IP 或代理机器 IP。直接拿它做 key，等于给攻击者送了免限流通行证。
正确顺序是：
- 优先取
$_SERVER['HTTP_X_REAL_IP']（需 Nginx 显式配置proxy_set_header X-Real-IP $remote_addr） - fallback 到
$_SERVER['HTTP_X_FORWARDED_FOR']，取逗号分隔后的第一个非私有地址（过滤127.0.0.1、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16） - 若业务已登录，强烈建议用解析
Authorizationheader 得到的user_id，比 IP 更稳定、更难伪造
别把 IP 和 user_id 混在一个 key 里——维度冲突会导致账号 A 被账号 B 的刷量连坐。
phpredis 扩展比 Predis 更适合高并发限流
Predis 是纯 PHP 实现，本地开发没问题，但上线后容易出现连接超时、返回空、管道批量失败等问题。尤其在短连接高频场景下，它的 socket 复用和错误重试逻辑不如 phpredis 稳健。
实操建议：
- 用
phpredis的incrBy、getSet、eval等原生命令，不要封装成“通用 Redis 类”再去套逻辑 - 连接池不是必须的，但至少要设
timeout=0.1和read_timeout=0.1，防止 Redis 卡住整个 PHP 请求 - Redis 不可用时，catch 到
RedisException或连接异常，直接返回true（放行），别重试、别降级到 file_put_contents 计数——限流是锦上添花，不是主干逻辑
真正容易被忽略的，是那个 Retry-After 响应头——429 时告诉客户端“等几秒再试”，比静默拒绝更利于前端做退避重试，也减少无效重刷。这个头得从 Lua 脚本里把窗口剩余时间算出来，再透传给 PHP 响应层。
