你說的是請求傳送簡訊驗證碼之前的圖形化完整吧！

這裡的驗證主要是為了避免機器註冊，眾所周知，平臺傳送一條簡訊驗證碼是需要成本的，如果被機器批次註冊，姑且不說驗證碼簡訊的無謂成本上升，而且帶入了一批無限的非潛在使用者資料。

如果你想說的是直接填寫號碼就確認為本人自己，你的問題是建立在自己填寫了正確的手機號碼為前提。還有一些異常情況沒有考慮，這裡問題還是很多的：

1.不小心填錯了自己的號碼，如果不加確認，第一次產生了一些使用記錄。後續如果透過正確的自己的號碼登入後，發現記錄是空的！是不是覺得很不可思議？

2.故意填錯自己的號碼，冒充了別人的號碼做了一些操作，如果這些操作產生了一些危害，如何追蹤該使用者（號碼）的責任？

3.對於平臺而言，透過號碼確認某種程度上是一個真實使用者的確認過程，為後續簡訊通知，二次啟用留下伏筆。

誠然簡訊驗證碼確實有一些弊端：

比如被判斷為垃圾簡訊，扔到了垃圾簡訊堆裡，簡訊到達率持續降低。所以也衍生出一些新的模式和手段，比如語音驗證碼，通訊運營商的一鍵驗證登入。

最後對於平臺來講，驗證碼是門戶，不但肩負著辨別真實使用者的職責。同事也是提現平臺體驗的第一步，如果沒有好的驗證碼體系，可能好不容易導流過來的使用者，不小心在這一步就流失了。一般使用者會考慮多通道主備：

1.主用常見的106開頭號碼簡訊通道

2.用非主流的互動式普通號碼簡訊通道

3.配備語音驗證碼通道

4.配備通訊運營商的一鍵登入SDK

正常情況下，每個真實的人都對應一個真實的手機號，設想一個場景，駭客知曉了你的使用者名稱密碼，然後發起轉賬，為了保證是本人操作，此時必須發起二次驗證，那麼顯然給使用者傳送一個動態密碼然後馬上驗證就比較好，可以透過手機，郵箱，動態密碼生成器（使用者提前預裝）等方式，綜上所述，傳送手機號是最方便的，而且也能幫助業務形成閉環。無論手機號是否實名，流程都應該這樣子設計，其次如果真的出事，那麼手機實名也只是起到錦上添花的作用，誰都不想隨便一點事情都去麻煩政府吧。