DRF的SimpleRateThrottle必须重写get_cache_key才能生效，因其默认仅对匿名用户限流；需返回非None字符串作为缓存键，且scope须与DEFAULT_THROTTLE_RATES中的键名一致，配合Redis缓存方可稳定生效。
DRF的SimpleRateThrottle必须重写get_cache_key才能生效
很多人配了DEFAULT_THROTTLE_RATES却没效果，根本原因是DRF默认只对匿名用户限流。只要用户已登录，AnonRateThrottle就完全不触发，而UserRateThrottle又默认按user.id限流——但你往往想按API路径、视图类甚至查询参数动态区分规则。
真正起作用的是继承SimpleRateThrottle并重写get_cache_key：它返回None表示不限流，返回字符串则作为缓存键参与计数。比如按URL路径+用户ID组合限流：
class PathUserThrottle(SimpleRateThrottle):
scope = 'path_user'
<pre class="brush:php;toolbar:false;">def get_cache_key(self, request, view):
if not request.user.is_authenticated:
return None # 匿名用户走另一套规则
return f'user_{request.user.id}_{request.path_info}'
注意：scope必须和DEFAULT_THROTTLE_RATES里的键名一致，否则配置不加载。
立即学习“Python免费学习笔记（深入）”；
如何在不同视图中启用不同限流策略
DRF不支持在settings.py里为每个视图单独配rate，得靠视图层显式声明。最灵活的方式是用throttle_classes属性，而不是全局配置。
-
APIView或GenericAPIView子类：直接设throttle_classes = [PathUserThrottle] -
ViewSet：可在类属性设，也可在具体action方法上用@action(throttle_classes=[...]) - 需要临时关闭限流？返回
None从get_cache_key即可，比注释代码更可控
别把所有视图都塞进同一个scope，否则修改速率要重启服务；拆成细粒度scope（如'login'、'search'），再在settings.py里分别配DEFAULT_THROTTLE_RATES = {'login': '5/min', 'search': '20/hour'}。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
Django 4下Redis缓存后端是限流稳定性的关键
DRF的SimpleRateThrottle底层依赖Django的cache，而Django 4默认的LocMemCache在多进程部署（如gunicorn多worker）时完全失效——每个worker维护独立内存缓存，限流形同虚设。
必须改用Redis：
CACHES = {
'default': {
'BACKEND': 'django_redis.cache.RedisCache',
'LOCATION': 'redis://127.0.0.1:6379/1',
'OPTIONS': {'CLIENT_CLASS': 'django_redis.client.DefaultClient'},
}
}
同时确认已安装django-redis，且INSTALLED_APPS包含django_redis。漏掉任一环节，throttle会静默退化为不生效，连错误日志都不抛。
调试限流失败时优先检查get_cache_key返回值和缓存命中
限流没反应，90%情况是get_cache_key返回了None或空字符串。加一行日志验证：
def get_cache_key(self, request, view):
key = f'user_{request.user.id}_{request.path_info}'
print(f'[Throttle] cache key: {key}') # 仅开发环境用
return key
生产环境建议用logging.debug并确保日志级别够低。另外，用redis-cli手动查键是否存在：
redis-cli -n 1 keys "throttle_*"
如果完全查不到，说明缓存没写入——大概率是缓存配置未生效，或者cache.set被异常中断（比如Redis连接超时但没报错）。
动态限流真正的复杂点不在写法，而在“什么时候该放行、什么时候该拦截”的业务判断。比如搜索接口要对高频关键词限流，就得在get_cache_key里解析request.GET.get('q')，还要考虑空值、编码、SQL注入风险——这些逻辑一旦写错，限流就变成漏洞。
