优先选tinywan/limit-traffic；因其默认用Lua脚本保障Redis原子性、自动注入标准限流响应头（X-Rate-Limit-Limit等）、中间件开箱即用，而webman/rate-limiter更适配注解级精细控制但需手动处理响应头与异常。
Webman 项目里加限流，不是装个包就完事——关键看用哪个组件、配在哪层、怎么应对并发和边界情况。官方 webman/rate-limiter 和社区 tinywan/limit-traffic 都能用，但行为差异明显，选错容易导致漏控或误拒。
用 webman/rate-limiter 还是 tinywan/limit-traffic？
两者都支持 Redis/Apcu/Memory 驱动，但核心区别在策略粒度和响应控制：
-
webman/rate-limiter原生支持注解（@RateLimiter），适合按控制器方法精细限流；默认不返回X-Rate-Limit-*头，需手动注入响应头逻辑 -
tinywan/limit-traffic自动注入标准限流响应头（X-Rate-Limit-Limit、X-Rate-Limit-Remaining等），且内置中间件开箱即用，但不支持注解，只能走全局或路由级中间件 - 若你依赖前端读取
X-Rate-Limit-Reset做退避重试，优先选tinywan/limit-traffic；若要给某个updateProfile()方法单独设 5 次/分钟，webman/rate-limiter更直接
限流中间件挂载位置影响实际效果
中间件注册顺序和作用域决定它是否真能拦住请求：
- 全局中间件（
config/middleware.php中''键下）会拦截所有请求，包括静态资源 —— 若你没排除/static/路径，图片、JS 文件也会被计数，可能误触阈值 - 路由级中间件（
Route::any('/api/v1/user', ...)->middleware([...])）只对匹配路径生效，但要注意：如果用了Route::group('/api', ...)却没在 group 内部显式调用->middleware()，中间件不会继承 - Webman 1.0.12+ 才支持路由组绑定中间件，旧版本必须每个子路由单独挂，否则形同虚设
Redis 驱动下 burst 和 rate 参数的实际含义
配置里写的 [100, 600] 是固定窗口，但底层用 Redis 实现时，并发场景下可能超限：
立即学习“PHP免费学习笔记（深入）”；
-
INCR+EXPIRE组合不是原子操作，高并发时两个请求几乎同时到达，都读到 99，各自INCR到 100，结果变成 101 —— 这就是“超卖”问题 -
tinywan/limit-traffic默认用 Lua 脚本封装原子操作，规避该问题；webman/rate-limiter的 Redis 驱动从 1.1.0 版本起才默认启用 Lua，低版本需确认是否开启use_lua配置项 - burst 参数在 Webman 里不直接暴露，它隐含在窗口重置逻辑中：固定窗口无平滑突发能力，想支持突发应换滑动窗口算法（需自行实现或改用第三方库如
php-rate-limiter）
自定义 429 响应体容易被忽略的兼容点
前端要求返回 200 OK + {"error_code": 429}，而不是原生 429 Too Many Requests，这事看似简单，实则有坑：
-
tinywan/limit-traffic提供onLimitExceeded回调，但该回调在中间件handle()内触发，此时响应对象尚未生成，不能直接调用response()->json()—— 必须 throw 自定义异常并在异常处理器中统一处理 -
webman/rate-limiter的注解限流在控制器执行前触发，同样无法直接 return 响应，得靠throw new HttpException(429, ...)并捕获 - 无论哪种方式，都必须确保异常处理器里清除了已写入的
X-Rate-Limit-*头（Webman 默认会在中间件里 setHeader），否则 200 响应里混着 429 语义的 header，前端解析会混乱
真正难的不是写限流逻辑，而是确认每种异常路径（如 Redis 连接失败、Lua 脚本执行超时、中间件顺序错位）下系统是否仍保持可控——这些点在线上压测时才容易暴露。
