最近遇到一個關于防止短信驗證碼被刷的產品設計問題，后來在面試一個前來應聘JAVA開發的程序員的時候，他也提到了他以前公司的系統也遭遇過這個被刷短信的問題。因此，就“如何設計短信驗證碼防刷機制”作一個總結和分享。

1、時間限制：60秒后才能再次發送

從發送驗證碼開始，前端（客戶端）會進行一個60秒的倒數，在這一分鐘之內，用戶是無法提交多次發送信息的請求的。這種方法雖然使用得比較普遍，但是卻不是非常有用，技術稍微好點的人完全可以繞過這個限制，直接發送短信驗證碼。

2、手機號限制：同一個手機號，24小時之內不能夠超過5條

對使用同一個手機號碼進行注冊或者其他發送短信驗證碼的操作的時候，系統可以對這個手機號碼進行限制，例如，24小時只能發送5條短信驗證碼，超出限制則進行報錯（如：系統繁忙，請稍后再試）。然而，這也只能夠避免人工手動刷短信而已，對于批量使用不同手機號碼來刷短信的機器，這種方法也是無可奈何的。

3、短信驗證碼限制：30分鐘之內發送同一個驗證碼

網上還有一種方法說：30分鐘之內，所有的請求，所發送的短信驗證碼都是同一個驗證碼。第一次請求短信接口，然后緩存短信驗證碼結果，30分鐘之內再次請求，則直接返回緩存的內容。對于這種方式，不是很清楚短信接口商會不會對發送緩存信息收取費用，如果有興趣可以了解了解。

4、前后端校驗：提交Token參數校驗

這種方式比較少人說到，個人覺得可以這種方法值得一試。前端（客戶端）在請求發送短信的時候，同時向服務端提交一個Token參數，服務端對這個Token參數進行校驗，校驗通過之后，再向請求發送短信的接口向用戶手機發送短信。

5、唯一性限制：微信產品，限制同一個微信ID用戶的請求數量

如果是微信的產品的話，可以通過微信ID來進行識別，然后對同一個微信ID的用戶限制，24小時之內最多只能夠發送一定量的短信。

6、產品流程限制：分步驟進行

例如注冊的短信驗證碼使用場景，我們將注冊的步驟分成2步，用戶在輸入手機號碼并設置了密碼之后，下一步才進入驗證碼的驗證步驟。

7、圖形驗證碼限制：圖形驗證通過后再請求接口

用戶輸入圖形驗證碼并通過之后，再請求短信接口獲取驗證碼。為了有更好的用戶體驗，也可以設計成：一開始不需要輸入圖形驗證碼，在操作達到一定量之后，才需要輸入圖形驗證碼。具體情況請根據具體場景來進行設計。

8、IP及Cookie限制：限制相同的IP/Cookie信息最大數量

使用Cookie或者IP，能夠簡單識別同一個用戶，然后對相同的用戶進行限制（如：24小時內最多只能夠發送20條短信）。然而，Cookie能夠清理、IP能夠模擬，而且IP還會出現局域網相同IP的情況，因此，在使用此方法的時候，應該根據具體情況來思考。

9、短信預警機制，做好出問題之后的防護

以上的方法并不一定能夠完全杜絕短信被刷，因此，我們也應該做好短信的預警機制，即當短信的使用量達到一定量之后，向管理員發送預警信息，管理員可以立刻對短信的接口情況進行監控和防護。

以上所說到的方式，或許不是很完美，但是可以通過多個方式結合著來作使用，通過多個規則來降低短信被刷的風險。