这确实是全栈项目里很常见的安全痛点——为了用户体验保留这类公共接口，但一不小心就会变成攻击者收集有效账号的工具。结合我做过的几个项目经验，分享几个大厂常用的防护手段，你可以根据自己的场景组合使用：

• 速率限制（Rate Limiting）
  这是最基础也最有效的手段。你可以针对IP地址或者注册流程的会话设置调用频率上限，比如1分钟内最多调用5次。超过限制就返回429 Too Many Requests状态码，还可以设置逐步延长的冷却时间。
  要注意的是，别只依赖IP限制——攻击者可以用代理池换IP，最好结合前端行为特征（比如检查请求是否来自真实的注册页面，而非直接调用接口），或者给每个请求绑定一个页面会话生成的临时token，增加批量调用的成本。

• 模糊化响应与耗时均衡
  别直接返回“用户名已存在”或“用户名可用”这种明确结果。比如不管结果如何，都返回类似“若该账号存在，我们将发送验证指引”的提示，把明确的存在性判断藏到后续注册流程里。
  另外，攻击者可能通过响应时间差判断结果（比如查询存在的用户记录耗时更久），所以要做耗时均衡——不管数据库查询结果如何，都统一延迟200-300毫秒再返回，抹平时间差。

• 无感知人机验证
  在用户多次调用接口后触发验证，比如前3次免费调用，第4次开始要求完成滑块验证或行为验证（分析鼠标移动轨迹、点击节奏等）。这种无感知验证不会太影响用户体验，但能有效阻挡批量脚本调用。
  如果你的注册流程本身有验证码，也可以把用户名检查接口和验证码绑定——只有验证通过后才允许调用检查接口。

• 会话绑定的接口权限
  不要把接口做成完全公开的无权限接口。比如要求请求携带注册页面生成的会话ID，服务器验证会话的有效性（比如会话是否是10分钟内从注册页面创建的）后才处理请求。这样攻击者很难批量调用，因为每个请求都需要先模拟注册页面的会话流程。

• 异常监控与自动拦截
  搭建简单的监控系统，跟踪接口的调用频率、IP分布、请求的用户名/邮箱特征。如果发现某个IP短时间内大量调用，或者请求的账号是常见字典词，就自动触发临时封禁或验证要求。
  你也可以维护一个异常请求特征库，比如攻击者常用的批量账号字典，在服务器端直接过滤这类请求。

• 数据最小化暴露
  接口只做存在性检查，不要返回任何额外信息（比如用户注册时间、登录次数）。同时数据库里的用户邮箱/用户名虽然是公开可检查的，但其他敏感信息一定要加密存储，就算攻击者拿到数据也无法直接使用。

其实大厂大多是多种手段组合使用，比如速率限制+模糊响应+行为验证，既能保证用户体验，又能有效防止滥用。你可以先从速率限制入手，这是最容易实现的，再逐步叠加其他防护措施。

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