在Web项目中，有一些请求或操纵会对数据产生影响（比方新增、删除、更新），针对这类请求平常都须要做一些庇护，以防备用户故意或无意的反复提议如许的请求致使的数据紊乱。
本文总结了一些防备客户端反复发送请求的要领。
要领一：JS监听Form的onsubmit事宜
在典范场景下，浏览器经由过程Form发送请求。因而只须要在Form onsubmit时将Submit按钮disable，就能够防备用户双击致使的反复请求（这类题目平常发作在年岁大的用户身上，他们分不清单击和双击）。
然则跟着前端的生长，Form之外的请求体式格局也越来越多，比方应用种种前端框架（Vue、AngularJs、Backbone等）写的App，他们更多的采纳的是ajax的体式格局和后端交互。那末前端开辟人员必需在开辟时针对每一个代表提议请求的UI元素做处置惩罚，像Form一样，在提议请求的时刻把相干UI元素禁用掉。
而有些交互体式格局则能够连代表提议请求的UI元素都没有，比方Segmentfault的markdown编辑器就是在一边输入的时刻一边保留的。那末这时候就须要前端代码采纳其他手腕来掌握反复请求的发作。
长处：
- 不须要后端写代码
瑕玷：
- 不存在一致的处理方案，必需针对每种状况写处置惩罚代码
- 无法掌握浏览器革新提议的反复请求
- 前端开辟人员遗忘写相干代码
- 无法掌握歹意的反复请求，比方绕过浏览器直接提议
要领二：Http Status Code 302（后端重定向）
服务端采纳重定向的体式格局，防备用户革新浏览器发出反复请求。这是比较典范的后端掌握反复请求的体式格局，由于一旦重定向胜利后，用户革新浏览器所革新的是谁人重定向地点，而不是数据操纵地点。
长处：
- 不须要写前端代码
瑕玷：
- 在还未相应302之前，所提议的反复请求，比方：用户疾速的双击、革新浏览器
- 在某些前端顺序里（比方SPA），不能运用重定向
- 后端开辟人员遗忘写相干代码
- 无法掌握歹意的反复请求，比方绕过浏览器直接提议
要领三：连系要领一和要领二
连系要领一和要领二的话却是能够处理大部分题目，然则处理不了以下题目：
- 在还未相应302之前，用户革新浏览器致使的反复请求
- 有些场景下压根不能运用重定向
- 前、后端开辟人员遗忘写相干代码
- 无法掌握歹意的反复请求，比方绕过浏览器直接提议
要领四：token体式格局
token的流程是如许的：
- 在浏览器发送请求前，先到服务端索要token
- 浏览器发送请求时，将token一并提交
- 服务端搜检请求是不是照顾token、token是不是有用（比方是不是准确、是不是逾期）。假如不准确则相应失利；假如准确则烧毁token，继承营业逻辑。
症结点在于：
- 每一个token都是一次性且有逾期时候的，能够防备token前端代码bug形成的反复应用和无穷应用。
- 服务器请求请求必需照顾token，能够防止前端开辟人员漏写相干代码。
那末token是以如何的情势传输的呢？我认为有以下两种体式格局：
Cookie：
引荐运用这类体式格局，由于浏览器每次都会将cookie照顾在请求里一并发出，所以前端发送请求的代码都不须要修正，只要在发送请求前问服务器拿token就好了。
比方在进入Form页面时，服务器将token以cookie的情势一并照顾在相应中，那末前端Form提交时，就会将cookie一并照顾在请求中，前端的代码一点都不须要修正。
json：
前端提议ajax请求像后端拿token，后端以json的情势返回token，前端发送请求时将token照顾在请求中，后端磨练。
这类体式格局比Cookie轻微贫苦的处所是，前端必需写一些代码来保留这个token，然后在发送请求的处所要写一些代码把token照顾在请求里。
长处：
- 前端代码能够写的少一些，比方禁用UI元素的代码能够不写
- 能够处理在还未相应302之前，用户革新浏览器致使的反复请求
- 顺应有些场景下压根不能运用重定向
瑕玷：
- 前、后端开辟人员遗忘写相干代码。这个真的处理不了。
- 无法掌握经由过程剧本运转的，具有整套流程的歹意请求。这类请求在顺序看来完整正当，但却属于歹意行动，针对这类歹意行动的防控属于另一个话题，本人不懂，所以在这里就不多讲了。
要领五：应用数据库的唯一束缚
假如请求会insert数据，而这个数据恰好存在营业主键，那末能够应用数据库的唯一束缚来做进一步的防备。
要领六：请求幂等化
有些营业情况下，请求是幂等的，这就意味着能够不必为反复发作请求而懊恼了——至少在营业逻辑层面不必懊恼了。
