PHP API限流需结合Redis滑动窗口与黑名单机制：用ZSET+Lua实现原子化毫秒级统计与清理，配合自动/手动黑名单封禁，并分层部署、降级兜底、规范监控与响应。
PHP API 限流不能只靠 PHP 自己计数，得用 Redis 的原子能力。滑动窗口解决固定窗口临界突增问题，黑名单兜底防暴力攻击——两者配合，才能在真实高并发场景下稳住接口。
滑动窗口限流：用 ZSET + Lua 保证原子性
核心是每个请求存一个毫秒级时间戳到有序集合（ZSET），每次检查「过去 N 秒内」的请求数，而不是「本分钟内」。关键不在于存多少数据，而在于三步必须原子执行：清理过期项、统计数量、写入新请求。
- key 设计推荐：
rate_limit:ip:{ip}或rate_limit:user:{uid}，优先用 user_id；若需兼容代理，记得解析X-Forwarded-For或X-Real-IP头取真实 IP - 用 EVAL 执行 Lua 脚本，传入参数：key、窗口毫秒数（如 60000）、最大请求数（如 100）、当前毫秒时间戳、唯一请求标识（如
req_+ microtime(true)） - 脚本内必须调用
ZREMRANGEBYSCORE清理0到now - window_ms的旧数据，再用ZCARD统计，仅当未超限时才ZADD写入 - 给 key 显式设 TTL，比如
EXPIRE key (window_sec + 1)，防止冷 key 持久占用内存
黑名单机制：自动封禁 + 手动干预双通道
限流只是减速，黑名单才是刹车。不是所有高频请求都该被放行——连续触发限流阈值多次，就该进黑名单；发现恶意 UA、异常参数组合，也该直接拦截。
- 自动封禁：在滑动窗口 Lua 脚本中增加逻辑，比如 5 分钟内累计超限 10 次，就写入
blacklist:ip:{ip}并设 TTL 3600 秒；后续请求先查这个 key，命中即拒绝 - 手动干预：提供后台或命令行工具，支持按 IP、user_id、设备指纹添加/删除黑名单，key 可统一用
blacklist:{type}:{value}格式，便于批量管理 - 注意区分层级：Nginx 层可做简单 IP 黑名单（
geo+map+deny），PHP 层做业务维度更细的判断（如某用户频繁刷优惠券接口）
PHP 实现要点：别踩这些坑
代码写得再漂亮，部署错一个细节就可能让限流失效或误杀正常用户。
立即学习“PHP免费学习笔记（深入）”；
- 时间戳必须用毫秒级（
microtime(true) * 1000），否则同一秒内多个请求会因 score 相同导致 ZADD 覆盖——member 必须唯一，建议拼接随机字符串或 UUID - 不要用
INCR + EXPIRE模拟滑动窗口，这是固定窗口，边界流量翻倍风险真实存在 - 避免在 PHP 层做多条 Redis 命令拼接（如先 ZCOUNT 再 ZADD），高并发下必然竞态；Lua 是底线，不是可选项
- 监控要跟上：记录被限流/拉黑的请求量、频次分布、top IP，用 Redis 的
KEYS rate_limit:*定期抽查 key 数量，防内存失控
生产环境建议：分层 + 降级 + 观测
限流不是加个脚本就完事，它得能扛住压测、能快速响应异常、能被运维看懂。
- Nginx 层用
limit_req做第一道防线（比如全局 QPS 限制），PHP 层专注业务逻辑级限流（如单用户每分钟调用发短信接口 ≤3 次） - Redis 故障时要有降级策略：比如配置开关，临时关闭限流；或 fallback 到本地 APCu 缓存（仅限单机小流量场景）
- 返回 HTTP 状态码要明确：
429 Too Many Requests表示限流，403 Forbidden表示黑名单；响应头带上X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset方便前端调试
