1

有可能卡住了还没 disabled ，用户又点了一次, 我们的做法是 {token}+url 做分布式锁的 key, 锁 1 秒后释放，否则提示请求过于频繁。

2

用户输入不可靠，你怎么判断是浏览器问题还是被爬虫了呢?

4

1

保证接口幂等呗

5

加一个 seq 参数，前端 js 确保每次主动调用的时候都是+1 的，后端过滤掉同会话下重复的 seq id(再重复就是业务流程的问题了

6

1

api 加个 uuid 和时间戳，比较时间范围和 uuid 重复

7

3

关键字：幂等性

8

每次请求带一次性 token ，用过后就作废。

9

保证接口幂等就好了呀，前端是可以做防抖，但那只是对用户体验的优化，不能从根本上解决问题。

10

更大的可能性是 js 事件重复绑定，手抖会有时间差的

11

判断 ip ，header ，body 跟上一次一模一样，而且时间间隔很短，例如 5 秒内，都认为是重复请求。
这个可能需要结合 redis 比较方便，ip ，header ，body 内容凑一起 md5 一下作为 key ，要返回的内容作为 value ，重复请求就从 redis 里返回上次的数据。
我没这么做过，纯属想象

12

接口在前面做个限流，1 秒 1 次

13

前端回传的表单中，可以额外增加一个计数器参数。每次点击提交按钮进行自增，如果你后台只想要第一次的请求，可以读取这个 index 来进行判断。一般也不用额外操作，保存在某个变量里就行，页面关闭刷新后 rest ，如果需要适应刷新，可以存到 cookie 里面，浏览器关闭后释放

14

1

直接让前端改就行了啊。 隐藏一个 int i =0; 提交之后+1 ， 第二次不让提交或者后端看到 i 不等于 0 就知道怎么处理了啊。

15

16

根据业务上幂等。

18

前段防抖或者后端针对用户做限流

20

为什么要判断？“除了请求的发送的时间不同，数据传过来是一模一样的” 上面说幂等的我想问一下，难道你们的接口在这种情况下多次请求的结果会不一样？？？

21

微信浏览器之前有这种相似的坑，微信浏览器客户端的请求会被微信服务器代理再发到 商户服务器……出现过莫名其妙的重复请求👿

22

@pengtdyd 比如说创建资源（订单）的接口，如果不增加额外的 限制，不幂等才正常吧

23

不同时间发过来的请求，入库之前先去表里查一下，已存在就直接返回前端，数据已存在
同时发过来的请求，后端加锁，相当于拒绝其中一个请求

24

用 redis 记录下状态

25

用 seq 来标记，客户端发起协议时候带上 seq ，服务器回复 seq+1 ，客户端更新 seq

26

对请求参数做 md5 校验，可以用 redis 控制时效

27

让前端改的都是伪后端，前端改只是用户体验，解决了根本问题了吗？

28

很显然你需要先定义好什么是重复请求，然后我估计解决办法也就有了。

29

行业共识：前端去重仅用于用户体验优化目的，业务上要想防止多花还是得由后端去重。