Cookie本身不能单独限制接口访问频率，但可作为用户身份标识配合服务端Redis计数和前端JS校验形成防刷辅助手段，关键在于增强会话可信度、降低脚本伪造成本。
Cookie 本身不能单独限制接口访问频率，但它可以作为用户身份标识的一部分，配合服务端逻辑（如 Redis 计数）和前端行为校验，形成轻量、可落地的防刷辅助手段。关键不是“靠 Cookie 拦人”，而是用它增强会话可信度、降低脚本伪造成本。
Cookie 用于识别“同一浏览器会话”
服务端在用户首次访问页面时，下发一个带签名的 Cookie（如 session_id=abc123; HttpOnly=false; SameSite=Lax），这个值不参与业务逻辑，仅作短期会话锚点。后续接口请求中，前端自动携带该 Cookie，服务端提取后与 IP、时间戳拼成限流 key（例如：rate:cookie_abc123:api/submit）。相比纯 IP 限流，它能更好区分同一局域网下的多个真实用户。
- 避免用 localStorage 或 sessionStorage 替代 —— 它们易被脚本直接读写，而 Cookie（尤其设了
SameSite和短过期）更难被跨域脚本滥用 - 不依赖 Cookie 值本身做鉴权 —— 它只是辅助标识，主校验仍走 session 或 token
- 每次生成新 Cookie 时建议加简单签名（如
HMAC(cookie_value + salt)），防止客户端篡改 key
结合 JS 运行环境校验提升有效性
单纯发 Cookie 没用，必须搭配前端 JS 主动参与。比如页面加载时执行一段脚本：
- 读取服务端下发的 Cookie 值
- 用它计算一个临时哈希（如
sha256(cookie + timestamp)），存入另一个非 HttpOnly 的 Cookie（如js_proof=xxx） - 表单提交或调用接口时，把这个
js_proof作为请求头或参数一并发出
服务端收到后：验证该 Cookie 是否存在、是否在 5 分钟内生成、哈希是否匹配。无 JS 环境的爬虫无法生成有效 proof，直接拦截。
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
立即学习“Java免费学习笔记（深入）”；
防止绕过：Cookie 不是唯一依据
攻击者可能手动构造 Cookie 或复用旧值。因此必须叠加其他维度：
- 时间阈值：前端记录页面加载到提交的毫秒数，低于 1.2 秒直接拒收
- Referer + UA 初筛：服务端检查请求来源是否为本站、UA 是否合理（空 UA 或明显爬虫 UA 直接丢弃）
-
IP + Session 双维度计数：Redis 中同时维护
ip:192.168.1.100:submit和cookie:abc123:submit两个计数器，任一超限即拒绝
实际部署注意点
Cookie 配合防刷不是开箱即用的功能，需注意三点：
- 设置
Max-Age=300（5 分钟），避免长期有效被复用；不设Domain防止子域名共享 - 所有涉及 Cookie 的接口响应头加上
Vary: Cookie，避免 CDN 缓存混淆 - 不要在错误提示里暴露“因 Cookie 无效被拒”——统一返回模糊提示，如“请求异常，请重试”
