优先选tinywan/limit-traffic；因其默认用Lua脚本保障Redis原子性、自动注入标准限流响应头（X-Rate-Limit-Limit等）、中间件开箱即用，而webman/rate-limiter更适配注解级精细控制但需手动处理响应头与异常。
Webman 项目里加限流，不能只看“有没有”，得看“在哪控、怎么控、控得住吗”。tinywan/limit-traffic 和 webman/rate-limiter 都能用，但选错会导致漏控（攻击流量穿过去）、误拒（正常用户被拦）或响应不兼容（前端拿不到 X-Rate-Limit-Remaining 做退避）。
tinywan/limit-traffic vs webman/rate-limiter 怎么选
核心差异不在功能多寡，而在控制粒度和响应契约：
-
tinywan/limit-traffic默认用 Lua 脚本保障 Redis 原子性，INCR+EXPIRE竞态问题不存在；自动注入X-Rate-Limit-Limit、X-Rate-Limit-Remaining、X-Rate-Limit-Reset头，前端可直接依赖；中间件开箱即用，适合全局或路由级粗粒度防护 -
webman/rate-limiter原生支持@RateLimiter注解，能精确到某个控制器方法（比如updateProfile()单独设 5 次/分钟）；但默认不返回标准限流头，需手动$response->withHeader()注入；Redis 驱动从 1.1.0 版本起才默认用 Lua，旧版本仍有超限风险 - 若你用前端重试逻辑（如读
X-Rate-Limit-Reset后 sleep 再发），优先选tinywan/limit-traffic；若要给某几个高危接口（如登录、密码重置）做差异化限流，webman/rate-limiter更灵活
中间件挂载位置决定它是否真生效
挂错位置，等于没挂：
- 全局中间件写在
config/middleware.php的''键下，会拦截所有请求——包括/static/js/app.js这类静态资源。若没排除路径，图片、CSS、JS 文件也会被计数，可能提前触发限流阈值 - 路由级中间件必须显式绑定：
Route::any('/api/v1/login', ...)->middleware([...])；Route::group('/api', function () { ... })不会自动继承中间件，除非你在 group 内部调用->middleware()（Webman ≥ 1.0.12 才支持） - 若用 Nginx 做反向代理，务必确认
X-Real-IP或X-Forwarded-For已正确透传，否则限流按127.0.0.1统计，全站变“一人一额度”
Redis 驱动下 [burst, rate] 参数的真实行为
配置写的是 [100, 600]（600 秒内最多 100 次），但底层实现决定它能不能守住这个数：
立即学习“PHP免费学习笔记（深入）”；
- 固定窗口算法本身有临界问题：第 599 秒发 100 次，第 600 秒又发 100 次，实际 2 秒内就 200 次——这是算法局限，和驱动无关
- 但并发场景下的“超卖”是驱动问题：
INCR+EXPIRE非原子操作时，两个请求同时读到 99，各自INCR到 100，结果变成 101；tinywan/limit-traffic默认用 Lua 封装，webman/rate-limiter≤ 1.0.x 版本默认不用 Lua，得手动配'driver' => 'redis_lua' - Apcu/Memory 驱动仅适合单机调试，集群环境必须用 Redis，且建议开启
redis_cluster或哨兵模式，避免单点故障导致限流失效
限流只是应用层防御的一环，别指望它扛住 DDoS
当攻击流量打满带宽或耗尽连接数，PHP 进程根本没机会执行——限流中间件连加载都做不到：
- 网络层必须前置清洗：用高防 IP 或 CDN（如酷番云）把 300Gbps 级攻击在边缘节点过滤掉，源站 PHP 完全无感
- 传输层靠系统调优：Linux 内核开启
net.ipv4.tcp_syncookies=1防 SYN Flood，缩短tcp_fin_timeout加快连接回收 - Web 服务器层加闸：Nginx 用
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s做第一道粗筛，比 PHP 层限流更早、更轻量 - 暴力破解类攻击（如登录接口）可结合 Redis 计数 + 指令过期（
SETEX login_attempts:$ip 300 5），但注意：PHP-FPM 子进程间不共享内存，必须依赖外部存储
真正容易被忽略的，是限流规则与业务真实水位的脱节——设了 100 次/分钟，但高峰期正常用户平均 80 次/分钟，那这个“防护”实际就是一道墙。上线前必须用真实流量压测，而不是只看插件文档里的默认值。
