WebAPI面试问题：用户连续点击按钮100次的服务端处理方案

是否会发送100次请求至服务器？ #

如果前端没有做任何防重复点击的处理（比如防抖、节流），大概率会有100次请求发送到服务器。浏览器默认会根据用户的点击动作依次发起HTTP请求，除非浏览器有特殊的缓存策略或请求合并机制，但这种情况极少发生。实际场景中，如果前端没做拦截，服务器会收到几乎所有重复请求。

WebAPI端处理重复请求的方案 #

• 实现接口幂等性：这是最核心的解决思路。
  • 对于PUT、DELETE这类天然应该幂等的请求，确保重复调用的业务结果完全一致；
  • 对于POST这类非幂等请求，要求客户端每次请求携带一个唯一的requestId，服务器用Redis或数据库记录已处理过的requestId，收到请求时先校验，若该ID已存在，直接返回之前的处理结果，不再执行业务逻辑。可以给requestId设置合理的过期时间（比如5分钟），避免存储资源浪费。
• 添加请求限流规则：针对同一用户、IP或接口设置限流阈值，比如10秒内最多允许5次请求。超出阈值的请求直接返回429（请求过多）状态码，拒绝处理。可以在API网关（如Nginx）或者后端框架（比如ASP.NET Core的RateLimiting中间件）中配置实现。
• 短时间重复请求过滤：基于用户标识（如用户ID、Token）+ 请求参数的哈希值，在Redis或内存中记录最近几秒（比如2秒）内的请求指纹。收到新请求时先对比指纹，若相同且在时间窗口内，直接返回上一次的响应结果，跳过业务执行。
• 请求合并处理：对于相同业务参数的重复请求，将它们放入临时队列，只执行一次业务逻辑，再把结果返回给所有等待的请求。这种方式适合允许轻微延迟的场景，能大幅减少服务器的重复计算。
• 快速返回失败响应：对于检测到的重复请求，直接返回400（无效请求）或自定义状态码，明确告知客户端请求重复，无需执行后续业务流程，节省服务器资源。

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