php中用redis实现滑动窗口限流最可控，需以用户标识+接口路径+时间戳区间拼key，用eval执行lua保证原子性，窗口粒度建议分钟或15秒，禁用$_server['request_time_float']而用microtime(true)切片。
PHP中用Redis实现滑动窗口限流
直接用 redis 实现滑动窗口是 PHP API 限流最可控的方式，比基于时间戳文件或数据库计数快得多，也比 apcu 更适合分布式部署。关键不是“能不能做”，而是窗口粒度、键名设计和原子性怎么保。
常见错误是把整个请求路径当 key，导致不同用户共用计数；或者用 INCR + EXPIRE 两步操作，中间可能被并发打断。
- 用用户标识（如
$userId或$ip）+ 接口路径 + 时间戳区间拼接 key，例如"rate:uid_123:/api/v1/orders:2024052014" - 用
redis->eval()执行 Lua 脚本，保证INCR和EXPIRE原子执行，脚本里判断是否超限并返回当前计数 - 窗口粒度建议按分钟或15秒切分，避免
KEYS扫描——不要依赖过期自动清理，而是在 incr 前先用SCAN清理陈旧 key（低频维护任务）
用PHP内置函数实现简单令牌桶（无Redis场景）
没有 Redis 时，apcu 是唯一靠谱的本地缓存选择。opcache 不支持 TTL，file_put_contents 并发写会丢数据，别碰。
令牌桶逻辑本身不难，但 PHP-FPM 下每个 worker 进程独立内存，apcu 是进程间共享的，这点常被忽略，导致限流失效。
- 桶容量、填充速率、上次填充时间都存进
apcu，key 命名为"token_bucket:{$ip}:{$endpoint}" - 每次请求先读取当前状态，计算应补充的令牌数：
min($capacity, $current + ($now - $last_fill) * $rate) - 检查是否够用，够则扣减并更新
apcu；不够就拒绝，返回429和Retry-After头 - 注意
apcu_enabled()必须为 true，且apc.enable_cli=1（如果跑在 CLI 模式下测试）
为什么不要用 $_SERVER['REQUEST_TIME_FLOAT'] 做滑动窗口时间切片
$_SERVER['REQUEST_TIME_FLOAT'] 看似方便，但它依赖系统时钟，NTP 同步或虚拟机休眠会导致跳变，造成窗口错位甚至计数归零。
更糟的是，在 FPM 模式下，这个值是请求进入 FPM 队列的时间，不是真正到达 PHP 的时刻，误差可能达几十毫秒——对 1 秒级限流就是致命偏差。
- 一律改用
microtime(true)获取当前精确时间 - 时间切片用向下取整：例如 15 秒窗口就用
floor(microtime(true) / 15)，而不是四舍五入 - 如果用 Redis，把时间戳作为 key 的一部分（如上文），不要存成 value 再比较，避免时区/精度转换问题
FastCGI / Nginx 层前置限流的坑
Nginx 的 limit_req 只能按 IP 或变量限流，没法区分登录用户；而且它在 PHP 执行前就拦截，无法结合业务逻辑（比如 VIP 用户放宽限制）。
更隐蔽的问题是：如果 PHP 层自己也限流，而 Nginx 把超限请求直接 503，PHP 根本收不到，日志里就看不到真实触发点，排查时会误判为“没生效”。
- 生产环境建议只选一层限流：Nginx 做粗粒度防护（防爬虫扫库），PHP 做细粒度控制（按用户角色、接口优先级）
- 若必须双层，让 Nginx 的
burst设大些，把真正决策权交给 PHP，并在 PHP 中记录原始 Nginx 限流头（如X-RateLimit-Limit）用于对齐 - 确认
fastcgi_ignore_client_abort off，否则客户端断连时 PHP 还在计数，导致后续请求被误拒
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
