在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數據，而這個數據正好存在業務主鍵，那么可以利用數據庫的唯一約束來做進一步的防御。

方法六：請求冪等化

有些業務情形下，請求是冪等的，這就意味著可以不用為重復發生請求而煩惱了——至少在業務邏輯層面不用煩惱了。