LFU因爬虫短时高频访问导致计数器迅速达上限63，污染热点判定，挤占真实高频Key；其衰减机制缓慢（需63分钟归零），且lfu-log-factor越大越难恢复；需网关层基于业务指纹限流、Redis侧跳过无效请求计数，并对高阶爬虫结合设备指纹与行为建模识别。
为什么爬虫会让LFU失效
LFU不是“看谁访问多”，而是“看谁长期稳定访问多”。爬虫批量扫一个Key（比如 /api/user/123），几秒内刷几百次，counter 会快速跳到 63（Redis LFU 最大计数器值），但这个Key实际根本没人用。等真实用户来访问时，它已经“假装”成热点，挤掉真正高频的 user:profile:current 或 config:feature:flag。
每小时自动在推特搜索中国、加密货币、国际热点、美国热点、特朗普等话题的热度信息，提取前十热点，依据 X 平台真实算法权重（开源代码数据）为每个热点生成高曝光推文或线程。用户提及“推特热点”“Twitter热点”“推特搜索”“热点推文”“生成推文”“社交媒体监控”“Twitter监控”等关键词时触发。
LFU计数器被爬虫污染后很难自动恢复
Redis 的 LFU 衰减机制靠 lfu-decay-time（默认 1 分钟）定期对所有 counter 做概率衰减，但：
- 衰减只作用于 counter > 0 的 Key，且每次最多减 1
- 爬虫打满后的 counter == 63，衰减要 63 分钟才归零
- 中间这段时间，它始终排在淘汰队列末尾，真实低频但稳定的 Key 反而先被淘汰
- lfu-log-factor 越大（如设为 100），初始增长越慢，但一旦突破阈值，后期几乎不衰减——对爬虫更不友好
网关层拦截必须基于请求指纹，不能只拦IP或UA
单纯限 IP 或 UA 容易误伤（比如企业 NAT 出口、合规爬虫、小程序 WebView），真正有效的拦截点是：
- 提取请求的「业务指纹」：path + query 参数签名（排除分页/时间戳类动态参数） + 用户身份标识（如 token 前缀或 device_id）
- 对指纹做滑动窗口计数（如 Redis INCR + EXPIRE 10 秒），单指纹 10 秒内超 5 次即拦截
- 拦截响应返回 429 Too Many Requests，**不透传到底层 Redis**，避免触发 LFUIncrAndReturn()
- 注意绕过登录态校验的接口（如商品详情页），需额外加设备指纹或行为特征（如 JS SDK 上报的鼠标轨迹熵值）
Redis 侧要配合关闭“无效访问”的计数更新
即使网关拦截了 99% 的爬虫，漏网请求仍可能进 Redis。可在应用层做二次过滤：
- 在 GET / HGET 前加轻量判断：若请求来自已知爬虫 UA（如 python-requests, curl/7.*/）且无有效 session cookie，直接跳过 GET，返回空或默认值
- 不调用 redisClient.get(key)，也就不会触发 LFUIncrAndReturn() 内部逻辑
- 对必须缓存的公开接口（如首页 Banner），改用固定 TTL + volatile-lfu 淘汰策略，不依赖频次计数器
真正难处理的是伪装成正常用户的高阶爬虫——它们带 Cookie、走完整登录流程、甚至模拟点击行为。这时候 LFU 本身已不是问题核心，得靠设备指纹 + 行为建模 + 请求链路染色联合识别。Redis 的 LFU 计数器，只该信任你确认过“是人”的流量。
