Yii2的RateLimiter需正确配置用户模型、存储后端和key粒度才生效；默认按$user->id限流，未登录用户共用ID=0导致刷爆；必须实现getRateLimit()和loadAllowance()，启用enableRateLimitHeaders，并推荐用Redis持久化。
Yii 框架本身不内置“开箱即用”的全局防刷开关，但它的 RateLimiter 行为提供了足够灵活、可落地的请求频率限制能力——关键在于你是否正确配置了用户模型、存储后端和限流 key 的粒度。
为什么直接配 RateLimiter 行为却没生效？
常见现象是加了行为但所有请求都走通，或未登录用户被统一限流（比如 1000 个游客共用 10 次/分钟配额），甚至返回头缺失。根本原因通常是：
-
RateLimiter默认依赖$user->id作为限流 key，而未登录用户会 fallback 到0—— 所有游客共享一个桶，极易被刷爆 - 用户模型没实现
getRateLimit()和loadAllowance()，框架退回到硬编码的 60 次/分钟（且只对已登录用户生效） -
enableRateLimitHeaders没设为true，导致前端看不到X-Rate-Limit-Remaining等响应头 - 没配持久化后端（如 Redis），默认用 PHP 内存缓存，多实例或重启后计数丢失
如何让每个 IP + 用户组合独立限流？
Yii 原生 RateLimiter 不支持按 IP 动态生成 key，必须重写 getKey() 方法。推荐在控制器里覆盖行为配置：
public function behaviors()
{
$behaviors = parent::behaviors();
$behaviors['rateLimiter'] = [
'class' => \yii\filters\RateLimiter::class,
'enableRateLimitHeaders' => true,
'key' => function ($request, $action) {
$userId = \Yii::$app->user->id ?: 'guest';
$ip = $request->getUserIP();
return md5("{$userId}_{$ip}");
},
];
return $behaviors;
}
注意：key 回调返回的字符串就是 Redis 或 DB 中的键名，务必保证唯一性且长度可控；若用数据库存配额，需确保 saveAllowance() 能根据这个 key 更新对应记录。
getRateLimit() 返回值怎么设才合理？
这个方法决定「谁」被限、「限多少」，不是全局配置，而是 per-user 的策略。典型误操作是写死 [10, 60] 对所有用户一视同仁：
- 管理员或 VIP 用户可能需要更高阈值，可基于角色返回不同数组：
return $this->isVip ? [100, 60] : [10, 60]; - 敏感接口（如登录、短信发送）应单独控制，可在控制器中禁用默认行为，改用自定义逻辑 + Redis 计数器（如
INCR+EXPIRE） - 时间窗口单位是秒，别把
[10, 1]当作“每秒 10 次”——它实际是“1 秒窗口内最多 10 次”，等效于令牌桶的突发容量，不是恒定速率
生产环境必须用 Redis，但要注意连接泄漏
Yii 的 RateLimiter 默认用 cache 组件，如果没显式配置 Redis 为 cache，则 fallback 到文件或 APCu，不适合集群。必须确认：
-
components['cache']已指向 Redis（yii\redis\Cache），且连接池健康 - Redis 实例启用了
maxmemory和淘汰策略（如allkeys-lru），避免限流 key 持续堆积占满内存 - 不要在高并发下频繁调用
loadAllowance()查询数据库——它会在每次请求时执行，应尽量用 Redis 存储allowance和timestamp
最易被忽略的是：当用户量极大时，md5("{$userId}_{$ip}") 这类 key 会产生海量离散键，Redis 内存碎片会上升明显，建议定期用 MEMORY USAGE 检查单 key 占用，并考虑按天分片（如加日期前缀）。
