Yii2服务端需用Redis缓存实现请求频次限制，核心是按用户/IP+路由生成带过期时间的键（如throttle:uid_123:action_submit），每次请求先校验缓存是否存在且未超时，配合ThrottleBehavior行为与可配参数（limitSeconds、keyPattern）实现原子性控制。
Yii 框架本身不提供类似前端 debounce 或 throttle 的 JS 式事件节流能力，因为它是服务端框架——高频点击最终体现为「短时间内大量重复请求」，必须在服务端拦截。直接在控制器里用时间戳或 Redis 记录用户行为，才是有效解法。
怎么在 Yii2 控制器里做请求频次限制
核心思路：对同一用户（或 IP + 路由组合）在指定窗口内只允许一次有效操作。不能依赖前端 JS 防抖，那层完全可绕过。
- 用
Yii::$app->cache（推荐 Redis 缓存）存键如throttle:uid_123:action_submit，值为时间戳，过期时间设为 2 秒 - 每次请求先
get()，若存在且距当前时间 throw new BadRequestHttpException('操作太频繁') - 否则
set()新键值，并继续执行业务逻辑 - 注意：不要用
session，它无法跨请求原子判断；也不要只用 IP，NAT 环境下会误伤
为什么不用 beforeAction + 时间戳数组
有人尝试在控制器里维护一个静态数组记录最近请求时间，这在 PHP-FPM 多进程环境下完全失效——每个 worker 进程持有独立内存，数组互不共享。你看到“限制生效”，只是巧合碰到了同一个 worker。
- 静态变量只在单次请求生命周期内有效，
static $times = []下次请求就清空了 - 即使加
file_put_contents写文件，高并发时会出现竞态，多个进程同时写导致覆盖或丢失 - 唯一可靠的是外部共享存储：Redis、Memcached 或数据库带行锁的
INSERT ... ON DUPLICATE KEY UPDATE
Yii3 中更简洁的写法（基于 EventDispatcher）
Yii3 支持事件驱动中间件风格，可把限流逻辑抽成独立行为，避免控制器污染。
- 定义一个
ThrottleBehavior，在beforeAction中检查cache->get($key) - 绑定到具体 action：
$this->attachBehavior('throttle', ThrottleBehavior::class) - 关键参数要可配：比如
limitSeconds => 3、keyPattern => 'throttle:{ip}:{route}' - 注意：Yii3 默认缓存组件是
NullCache，务必在 config 中配置真实缓存驱动
真正难的不是写几行代码，而是确认「谁来承担限流失败的后果」：前端按钮禁用只是体验层，后端没拦住，订单重复创建、积分重复发放、短信重复下发——这些都得靠服务端原子性控制。别让防抖变成心理安慰。
