真实线上限流必须用滑动窗口+可信IP提取+Lua原子脚本：固定窗口会在整点突增流量导致计数失效；REMOTE_ADDR易被代理污染，需按X-Real-IP/X-Forwarded-For顺序校验；Redis多命令非原子，须用Lua封装ZSET滑动窗口逻辑。
PHP API 限流不能只靠 $_SERVER['REMOTE_ADDR'] + Redis::incr() 就完事——高并发下会丢计数、IP 会被代理头污染、固定窗口会在整点突增流量，真实线上必须用滑动窗口 + 可信 IP 提取 + Lua 原子脚本。
为什么固定窗口限流在生产环境容易失效
固定窗口（比如“每分钟最多 60 次”）看似简单，但实际会在时间边界处放大风险：用户在第 59 秒发起 60 次请求，又在第 0 秒发起 60 次，等于瞬间 120 次。后端没感知到压力突变，数据库连接池直接打满。
常见错误现象包括：
- 监控显示 QPS 突增一倍，但 Redis 计数器没超阈值
- 同一 IP 下多个登录用户互相干扰（
rate_limit:1.2.3.4键太粗） - 限流日志里大量
429出现在整点前后，非业务高峰时段
解决方案是改用滑动窗口，核心是用 ZSET 存时间戳，每次请求执行 ZCOUNT 统计当前窗口内请求数。但注意：ZADD 和 ZREMRANGEBYSCORE 必须原子执行，否则并发时可能漏删旧数据——必须封装进 Lua 脚本。
立即学习“PHP免费学习笔记（深入）”；
如何正确提取客户端真实 IP
$_SERVER['REMOTE_ADDR'] 在有 Nginx、CDN 或负载均衡的架构下，几乎总是内网地址（如 10.0.1.5 或 127.0.0.1），直接拿它限流等于失效。
必须按顺序检查可信代理头：
- 优先读
$_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） - 绝不能信任未校验的
X-Forwarded-For—— 攻击者可伪造为任意 IP
示例判断逻辑（不依赖第三方库）：
$ip = $_SERVER['REMOTE_ADDR'];
if (!empty($_SERVER['HTTP_X_REAL_IP'])) {
$ip = $_SERVER['HTTP_X_REAL_IP'];
} elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$ips = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
foreach ($ips as $candidate) {
$candidate = trim($candidate);
if (!filter_var($candidate, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
continue;
}
$ip = $candidate;
break;
}
}Redis 滑动窗口必须用 Lua 脚本保证原子性
PHP Redis 扩展的 zAdd() + zRemRangeByScore() + zCard() 是三个独立命令，中间可能被其他请求插入，导致计数偏高或过期清理失败。
正确做法是把整个滑动窗口逻辑写进 Lua 脚本，通过 EVAL 一次性提交。例如限制「最近 60 秒最多 100 次」：
local key = KEYS[1]
local window = tonumber(ARGV[1])
local max = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
<p>-- 清理过期时间戳
redis.call('zremrangebyscore', key, 0, now - window)
-- 添加当前时间戳
redis.call('zadd', key, now, now)
-- 设置过期（防止 key 永久残留）
redis.call('expire', key, window + 10)
-- 获取当前窗口内请求数
local count = redis.call('zcard', key)</p><p>if count > max then
return {0, count}
else
return {1, count}
endPHP 中调用：
$result = $redis->eval($lua_script, 1, $key, $window, $max_requests, time());
list($allowed, $current_count) = $result;
if (!$allowed) {
http_response_code(429);
header('Retry-After: 1');
echo json_encode(['error' => 'Too many requests']);
exit;
}限流响应要带 Retry-After 且异步记录日志
返回 429 Too Many Requests 时，必须设置 Retry-After 响应头，告诉客户端多久后可重试。固定窗口可设为窗口剩余秒数；滑动窗口建议统一设为 1 秒（因窗口是滚动的，精确值难算）。
更关键的是日志记录：别在限流判断后、echo 前直接 file_put_contents()，I/O 会拖慢所有放行请求。正确姿势是：
- 限流检查（Redis 操作）必须同步完成，决定是否放行
- 放行后立即调用
fastcgi_finish_request()，让 Web Server 关闭连接 - 再执行日志写入、监控上报等耗时操作，不影响用户响应时间
容易被忽略的一点：限流键名设计要支持多级维度。例如 rate_limit:uid_123:api_v1_orders，而不是笼统的 rate_limit:1.2.3.4 —— 否则一个 IP 登录多个账号会互相锁死，VIP 用户也无法单独提额。
