表单与机器人的限流、队列和反垃圾
限流（rate limit）、队列和反垃圾是三层防护 - 没有它们，表单和 Telegram/Discord 机器人很快会变成垃圾、刷屏和 DoS 的通道。单靠 CAPTCHA 不够：需要频率限制、异步处理，以及对内容和信誉的过滤。下面 - 如何在不过度复杂的前提下，为网站和机器人搭一套可落地的方案。
- Rate limit - 同一 IP、账号或令牌在时间窗口内允许多少次请求
- 队列 - 接收请求与重活（邮件、CRM、LLM、webhook）之间的缓冲
- 反垃圾 - honeypot、CAPTCHA、启发式、黑名单和内容检查
- 原则 - 先压频率并异步处理，再加强过滤器
- 目标 - 留住真人线索，并在僵尸网络冲击下保持服务可用
- 对企业意味着什么 - CRM 和邮箱里的垃圾更少，短信/LLM/API 账单更低，销售只看到真实线索
为什么表单和机器人最先被打
公开接口等于没上锁的门。垃圾机器人会扫 /contact、/api/lead 和机器人 webhook，然后海量投递：钓鱼、SEO 垃圾、撞库、暴力破解优惠码。没有限制时，邮件/短信/LLM 账单上涨，CRM 被垃圾填满，真实线索淹没在噪声里。
常见症状：
- 表单 POST 暴增，销售转化却为零
- 不同 IP 发相同文案 - 或同一网段发「各不相同」的垃圾
- 邮件或 webhook 队列撞上服务商限额
- 即时通讯机器人应答变慢或超时
Rate limit：限制什么、怎么限
限流回答的是：「这个接口在 N 秒内可以被打多少次？」限流键很关键。
| 键 | 适用场景 | 风险 |
|---|---|---|
| IP | 匿名表单、无鉴权 webhook | NAT 与企业网会误伤好人 |
| User / chat_id | 已登录 API 与机器人 | 登录前无效 |
| API 令牌 / 会话 | 合作方集成 | 令牌被盗会耗尽整份额度 |
| Fingerprint + IP | 强表单反滥用 | 实现与对用户解释更难 |
实用窗口：
- 线索表单： 每 IP 每 10 分钟 3-5 次成功提交，并对失败（校验失败、CAPTCHA 失败）设更严上限
- 登录 / OTP： 单独且更严 - 否则容易被爆破
- 机器人命令： 每个用户每隔几秒允许 1 次重应答（生成、搜索）；轻命令可更松
- 进程或 worker 的全局上限 - 即使键不同，也能扛住尖峰
超限时：返回 HTTP 429 与 Retry-After；在机器人里简短提示「请等待 N 秒」，不要暴露内部阈值。记录触发日志：可以看出限额偏松还是偏紧。
队列：为何要把接收与处理分开
表单不应同步写 CRM、生成 PDF 再调外部 API。队列（Redis、RabbitMQ、SQS、Celery、BullMQ）在校验后立刻接任务，并向用户快速返回：「请求已受理」。
队列带来的收益：
- 削峰 - 垃圾或投放高峰不会拖垮 Web 进程
- 失败重试 - 带 backoff 的 retry，而不是丢线索
- 优先级 - 已付款订单高于「下载 PDF」
- 隔离 - LLM/邮件 worker 与前端独立扩缩
表单流程：
- CSRF / origin、honeypot、字段基础校验
- Rate limit
- 将线索写入数据库，状态为
queued - 推入队列
- 向用户返回 HTTP 200/202
- Worker：反垃圾打分 → CRM / 邮件 / 通知
机器人同理：快速接收 Telegram 更新；重应答（RAG、出图、解析）进队列。否则 long polling / webhook 延迟会堆积。
反垃圾：多层，而不是一个勾选框
一个 reCAPTCHA 解决不了问题。要做纵深防御。
1. 入口处的廉价过滤
- Honeypot 字段（对人隐藏，机器人会填）
- 最短填写时间（过快 = 机器人）
- 校验
Referer/Origin与 CSRF 令牌 - 限制请求体大小与附件数量
2. CAPTCHA 与挑战
按信号展示挑战，而不是永远展示：N 次尝试后、可疑 IP、高分风险。常驻 CAPTCHA 伤转化；按需几乎不伤。
3. 内容与信誉
- 文案中的域名/URL 黑名单
- 识别重复模板与跨语言垃圾
- 邮箱检查（MX、一次性域名）
- 机器人侧：链接过滤、停用词、媒体上限
4. 行为信号
历史：该设备提交有多少变成成交或有意义对话。新 IP 一分钟内几十条「buy SEO」应进隔离区或人工审核，而不是直接进销售 CRM。
如何把三层串起来
生产环境建议顺序：
- 校验与廉价反垃圾（honeypot、大小、CSRF）
- 按 IP + 用户/chat id 限流
- 快速响应客户端 / 即时通讯
- 队列，并为每个 worker 设并发任务上限
- 在 worker 中做重反垃圾与集成（打分、CRM、邮件）
- 告警：429 尖峰、被拒任务增长
这样就不会把 CPU 和服务商预算浪费在本该被限额挡住的请求上。
落地检查清单
- [ ] 表单与机器人按风险设置不同限额
- [ ] 对外邮件/短信/LLM 有全局熔断
- [ ] 429 与机器人提示对人清晰，但不暗示如何绕过
- [ ] 队列有 DLQ（死信）与长度监控
- [ ] 可疑线索进隔离区，而不是静默删除
- [ ] 限流与垃圾分日志可按 IP/哈希、endpoint 和 score 排查，无需完整访问个人数据（姓名、邮箱、电话、申请正文）
- [ ] 压测：
/contact在 100 RPS 时会发生什么
什么时候还不用做这么复杂
不是每个项目都要一开始就上全套方案：
- 没有表单或机器人的静态网站 - 没什么可防护的，不需要限流
- 每天线索不到 10-20 条且不调用外部 API/LLM - 托管/CDN 层面的验证码加限流（Cloudflare、Nginx）就够了，单独上队列还不划算
- 早期 MVP - 先验证市场是否需要这个产品，等流量和真实攻击增多后再加反垃圾和队列
- 已经有托管防护（Cloudflare、WAF、自带反垃圾的表单）- 先用足它的限流和过滤，不要从零重复建设
如果流量和集成数量增长，再回到上面的完整方案。
小结
限流压频率，队列护住后端与集成预算，反垃圾把垃圾与线索分开。三者必须一起用：有限额无队列仍会打垮同步处理；有队列无过滤会把垃圾灌进 CRM；有过滤无限额在 DDoS 下会变得很贵。
若需要按你的技术栈设计表单与机器人防护（限额、队列、隔离区、监控）- 请联系我。支持与迭代参考见价格页。
常见问题
限流和反垃圾有什么区别？
限流数次数；反垃圾看内容与行为。 限额即使面对「干净」请求也能挡住刷屏；反垃圾能抓住次数不多但仍有毒的垃圾。
线索量很少还需要队列吗？
需要，只要有外部 API、邮件或 LLM。 即便流量低，同步 CRM 超时也会毁掉表单体验。队列空闲时成本低，峰值时能救命。
每个表单都必须上 CAPTCHA 吗？
不必。 更宜按风险展示挑战：错误连发后、IP 信誉差、或异常分数时。少打扰真人，仍能挡机器人。
机器人按 chat_id 限还是按 IP 限？
两个都要。 chat_id 挡住单用户刷屏；IP/webhook 令牌防御伪造更新与扫描。群组限额通常比私聊更严。
看起来像垃圾的线索怎么办？
进隔离区做人工复核或延迟投递，不要无痕迹丢进垃圾桶。否则会丢掉偶发真线索，也看不到攻击模式如何演变。
本文术语
rate limit — cap on how many requests are allowed per time window — 单位时间内允许的请求上限
CRM — Customer Relationship Management — 客户关系管理
webhook — HTTP callback when an event happens — 事件发生时触发的 HTTP 回调
LLM — Large Language Model — 大语言模型
worker — background job processor
Celery — Python task queue for background jobs — Python 后台任务队列
backoff — growing wait between retries after failures — 失败后重试间隔逐渐加长
long polling — client waits on an open request until the server has news — 客户端保持请求打开直到服务端有消息
retry — automatic repeat of a failed request or job — 失败请求或任务的自动重试
CSRF — Cross-Site Request Forgery — 跨站请求伪造
RAG — Retrieval-Augmented Generation — 检索增强生成
endpoint — specific API URL that accepts requests — 接受请求的具体 API 地址
CDN — Content Delivery Network — 内容分发网络
MVP — Minimum Viable Product — 最小可行产品
DDoS — Distributed Denial of Service — 分布式拒绝服务攻击
WAF — Web Application Firewall — Web 应用防火墙