如何移除URL中的自增ID且旧URL可正常运行一段时间？

首先明确核心需求：既要用无规律的URL替代可遍历的自增ID格式，保护数据不被竞品爬取，又要确保真实用户的旧收藏/推广链接能正常访问，同时封堵爬虫通过旧URL遍历的路径。以下是几个可行的落地方案：

一、设计不可预测的新URL结构 #

第一步先替换核心的URL标识，彻底断绝遍历可能：

• 给每个房源新增一个带盐哈希值或UUID字段（比如flat_slug），存储在数据库中。例如用SHA256(id + 随机盐值)生成唯一且无规律的字符串，或者直接用UUID v4。
• 新URL格式改为/flats/{flat_slug}，比如/flats/7a2f9d4c-1b3e-5f7a-9b2d-4c6e8a0b2d4f或/flats/8kLzPmQrStUvWxYz。
• 确保这个新slug无法通过自增ID反向推导（加盐哈希是关键，盐值要保密，不要硬编码在代码里）。

二、旧URL的兼容与爬虫拦截策略 #

针对旧URL/flats/{id}，不能直接开放或永久重定向，需要区分真实用户和爬虫请求：

方案1：基于用户会话/可信来源的访问控制 #

• 规则：仅允许有合法会话或来自可信推广渠道的请求访问旧URL，无验证的陌生请求直接返回404。
• 具体实现：
  • 对于登录用户：检查会话中是否有该用户的浏览/收藏记录，若存在则放行，内部跳转到新URL（返回新URL的内容，或返回302重定向给用户，让浏览器地址栏更新为新URL）。
  • 对于未登录用户的收藏/推广链接：在旧URL中添加签名验证参数，比如推广链接生成时改为/flats/{id}?token={signature}，其中signature是用id + 盐值 + 过期时间生成的哈希值。服务器收到请求时先验证token的有效性（是否过期、哈希是否匹配），验证通过才放行。
  • 对于无会话、无有效token的请求：直接返回404，不给爬虫任何遍历的机会。

方案2：速率限制+爬虫特征识别的混合拦截 #

• 规则：对旧URL的请求设置严格的速率限制，同时识别爬虫的请求特征，拦截批量遍历的请求，放行真实用户的单次请求。
• 具体实现：
  • 用Redis等工具记录每个IP对旧URL的请求频次，比如1分钟内最多允许3次请求，超过则返回429（Too Many Requests）。
  • 识别爬虫请求特征：检查User-Agent是否为无头浏览器（如HeadlessChrome）、是否缺少真实浏览器的请求头（如Accept-Language、Referer）、是否有批量请求的时间规律（比如间隔固定的请求）。符合特征的请求直接返回403或404。
  • 真实用户的正常请求（比如从收藏夹点击一次、从朋友圈打开推广链接一次）不会触发速率限制，且请求头符合真实浏览器特征，会被放行，同时自动重定向到新URL。

方案3：逐步淘汰旧URL的过渡策略 #

如果需要更稳妥的长期方案，可以分阶段关闭旧URL：

1. 第一阶段（1-3个月）：仅对有历史访问记录的用户（通过cookie识别）开放旧URL，新用户访问旧URL直接跳转到网站首页或搜索页，同时在网站公告栏提示用户更新收藏链接。
2. 第二阶段（再1-2个月）：仅对带有有效推广签名的旧URL放行，其他无会话的旧URL请求返回404。
3. 第三阶段：完全关闭旧URL的访问，所有请求直接返回404或跳转到新URL的搜索结果页。

三、额外的防护补充 #

• 不要在页面源码、API响应中暴露自增ID：比如之前的页面可能会在HTML里输出data-id="123"，要改成输出data-slug="7a2f9d4c..."，彻底隐藏自增ID的存在。
• 对新URL也添加基础的反爬措施：比如速率限制、验证码（针对高频请求）、会话验证，防止竞品通过其他方式爬取新URL。

内容的提问来源于stack exchange，提问作者yajiv