网站运营搜索建议API应限制返回结果数量防止爬虫滥用

搜索API不设防，等于把数据库的钥匙直接挂在门外。很多站点开放了站内搜索接口，返回数据量没有上限，爬虫可以轻松遍历全部商品、文章或用户数据。限制返回结果数量不是可选项，而是基础防御动作。具体做法是在服务端对page参数和size参数做硬限制，例如单次请求最多返回20条，且最大页码不超过100页。即便对方伪造参数，后端也要在SQL查询前做一次强制类型转换和范围校验，超过阈值直接返回空集或固定错误码。

还有一种更隐蔽的滥用方式是通过偏移量拼接数据。攻击者不碰size上限，而是用offset=0、offset=20、offset=40的方式把全量数据拉走。所以光限制单页条数不够，必须对单IP或单Token的累计访问深度做控制。可以设定一个滑动窗口，比如每分钟内同一身份标识最多只能访问前1000条记录，超过就触发验证码或临时封禁。这个累计阈值要根据自身数据总量来定，核心原则是让遍历成本远高于数据价值。

很多开发者在做搜索接口时，习惯把total数也一并返回，这等于主动告诉爬虫“我还有多少数据等着你拿”。正确的做法是，当结果集超过一定阈值时，total字段不再返回真实值，而是返回一个固定上限，比如“超过1000条”就显示1000。前端展示“约1000条结果”即可，不影响正常用户判断，但爬虫无法据此计算遍历策略。

另外，API返回的字段也要做最小化处理。搜索列表接口不应该返回详情页才有的完整字段，比如文章正文、用户手机号、商品成本价等。列表只返回标题、摘要、时间、ID这些必要信息，详情再走单独的、带权限校验的接口。这样即便有人突破了数量限制，拿到的也只是摘要级数据，无法直接用于竞品分析或数据倒卖。

限制返回结果数量只是第一层，速率限制是第二层。正常用户的搜索行为有停顿、有修改关键词、有翻页浏览，而爬虫的请求间隔高度均匀，且翻页速度极快。可以在网关层对搜索接口做令牌桶限流，默认单用户每秒1-2次请求，翻页行为额外做间隔检测。如果同一会话在500毫秒内连续翻页超过5次，直接打标并降低其配额。

行为识别方面，可以引入简单的熵值计算。正常搜索词的长度、字符分布、语义连贯性都有规律，而爬虫常用遍历词库或数字序列，比如“商品001”“商品002”这种模式。对搜索词做模式匹配，发现连续数字递增或字典序遍历的特征，就触发风控。这套逻辑不需要复杂的AI模型，用正则加统计算法就能拦住大部分低水平爬虫。

游标分页比偏移量分页更抗爬。偏移量分页的致命缺陷是，爬虫可以并行发起多个请求，每个请求从不同offset开始，几台机器同时跑就能快速拉完全库。而游标分页要求每次请求携带上一次返回的cursor，服务端用这个cursor做索引定位，天然串行化，大幅拖慢遍历速度。实现上可以用主键ID或ES的search_after机制，cursor本身做签名防篡改。

// 游标分页示例：cursor用base64编码并加HMAC签名
function encodeCursor(lastId, timestamp) {
  const payload = `${lastId}:${timestamp}`;
  const signature = crypto.createHmac('sha256', SECRET).update(payload).digest('hex');
  return Buffer.from(`${payload}:${signature}`).toString('base64');
}

function decodeCursor(cursor) {
  const decoded = Buffer.from(cursor, 'base64').toString('utf8');
  const parts = decoded.split(':');
  // 验证签名，防止cursor被伪造
  const expectedSig = crypto.createHmac('sha256', SECRET).update(`${parts[0]}:${parts[1]}`).digest('hex');
  if (parts[2] !== expectedSig) throw new Error('Invalid cursor');
  return { lastId: parseInt(parts[0]), timestamp: parseInt(parts[1]) };
}

还有一种更彻底的方案是禁用深度分页。对于搜索结果，只允许浏览前N页，比如前5页共100条结果。如果用户确实需要更精确的结果，应该引导其使用更精准的搜索词或筛选条件，而不是无限制翻页。这种做法对用户体验影响很小，因为真实用户很少翻到第10页以后，但爬虫的全量抓取路径被直接切断。

搜索接口的缓存策略也直接影响被爬的风险。如果每次请求都穿透到数据库或搜索引擎，不仅性能差，还给了爬虫实时获取最新全量数据的机会。可以在业务允许的范围内对热门搜索词做1-5分钟的缓存，这样同一关键词的频繁请求不会反复消耗资源，同时爬虫拿到的数据有一定延迟，降低时效性价值。

数据混淆方面，可以对返回的列表顺序做微量随机化。正常搜索结果是按相关性排序的，但可以在同相关性分值的记录之间做随机排列，这样每次请求返回的顺序略有不同，爬虫无法通过对比多次抓取结果来验证数据完整性。另外，可以在列表中随机插入1-2条与搜索词弱相关但不影响整体体验的结果，干扰数据清洗的准确性。

未登录用户的搜索接口是最容易被滥用的，因为没有身份绑定的限流很容易被换IP绕过。建议对未登录用户设置更严格的限制，比如每分钟最多5次搜索、每次最多返回10条结果、不支持高级筛选。登录用户则根据账号等级逐步放开，但也要有上限。关键是把搜索能力与身份强绑定，让滥用成本从“换个IP”变成“注册并养一个账号”。

设备指纹也是一个有效的辅助手段。在搜索请求中植入前端采集的设备指纹参数，服务端结合IP和指纹做关联分析。同一个指纹换IP、或者同一个IP换指纹，都能被识别出来。这套机制不需要绝对精准，只要能增加爬虫开发者的逆向成本就够了。指纹算法可以用开源方案自建，不必依赖第三方服务。

限制措施上线后，必须配合实时监控。重点监控的指标包括：单IP的搜索请求量、搜索结果的点击率、搜索词的集中度、翻页深度分布。正常用户的搜索到点击转化率通常在20%-60%之间，而爬虫只搜不点，转化率接近零。一旦某个来源的搜索点击率持续低于5%，基本可以判定为异常流量。

应急响应层面，建议预设几档自动处置策略。第一档是弹出验证码，第二档是返回空结果但状态码正常，第三档是返回随机假数据。返回假数据这招尤其有效，因为爬虫方很难快速判断数据真伪，等他们发现数据有问题时，已经浪费了大量时间和存储成本。假数据要做得像真数据，比如标题结构一致、时间戳合理、ID符合规则，但内容无实际价值。

把搜索API的防御从应用层延伸到架构层。搜索服务独立部署，分配独立的数据库只读副本，这样即使搜索接口被打穿，也不会影响主业务流程。搜索接口的数据库账号只授予必要的SELECT权限，且限制查询超时时间，防止慢查询拖垮库。在搜索服务前面再加一层反向代理，由代理层统一处理限流、鉴权、日志采集，应用层只处理合法的业务请求。

对于数据量大的站点，可以考虑把全量搜索和模糊搜索分开。全量搜索即无关键词的浏览型请求，这类请求对爬虫价值最大，应该做最严格的限制。模糊搜索即带关键词的查询，可以相对宽松。两者的限流策略分开配置，避免正常用户的精准搜索被全量浏览的滥用行为连累。

最后要强调的是，这些限制措施需要定期复盘调整。业务在增长，数据量在变化，爬虫的手段也在升级。每个季度至少做一次搜索接口的滥用压力测试，模拟爬虫行为看能否绕过限制，根据测试结果迭代规则。限制返回结果数量是起点，不是终点，整个防御体系需要持续演进。