起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識實例分析拆解：如何設計登錄注冊？
登錄注冊流程看似簡單，實際考量設計功力。網上關于登錄注冊的綜述有很多了，但是從零到一整合分析的很少，以下，將以實際的產品為例，精細分析如何設計賬戶體系。
最近對我們的APP的賬戶體系進行了改版，研究了各類產品的設計。賬戶體系雖然幾乎是通用標配功能，但是各APP的都有差別，都是針對當前的產品形態、發展階段和用戶量級做出了符合自己的設計。
賬戶體系的關鍵點在登錄注冊流程上。
一、立項背景
我們的產品第一版賬戶體系由于歷史原因，做的比較生硬。
初期主攻社交，希望可以沉淀用戶信息，手機賬號會是第一優先選擇，當時的方案是手機號注冊+賬號密碼登錄/第三登錄+立刻綁定手機賬號。
如你日常體驗那樣，第三方登錄+立刻綁定手機的方式，直接抵消了第三方登錄的便利，比直接手機號注冊更麻煩。而且，設計上，手機號注冊需要設置兩次密碼，密碼需要一致；設置之后，還得進入登錄界面，再次填寫賬號密碼，正確匹配才可以進入APP。
總的來說，用戶進入APP的路徑相當長，步驟多，用戶體驗低分。
近況是，產品方向探索，將重點落在商城上。完成交易的流程本身就多步驟，再疊加原來的登錄注冊，路徑過深，對拉新損耗大，急需改進。
二、需求分析
從業務發展趨勢來看，微信會是重要的用戶來源，后續會布局更多的微信運營活動，和商城小程序，設計引流到APP，需重點突出微信登錄。
而商城交易需要保證安全性，同時兼容老用戶，手機注冊密碼登錄必不可少?？紤]到用戶文化水平，和互聯網產品使用習慣，需要在常規的基礎上做簡化。
第三方登錄需要在關鍵點綁定，商城推廣員提現時變更銀行卡，需加以驗證身份。
新用戶剛進來，可以先瀏覽熟悉產品內容，在需要身份信息時，再進行引導登錄。
三、功能點梳理
登錄注冊流程：微信/QQ第三方登錄、驗證碼登錄/注冊、密碼登錄、找回密碼。
賬戶體系配套：關鍵點引導綁定手機、關鍵點強制綁定手機、驗證碼驗證賬號、賬號相互綁定。
細節功能點見下方的賬戶體系功能點梳理圖。
四、流程圖（登錄注冊）
未登錄用戶，到達需要獲取用戶身份信息的界面（為了平衡效率和體驗，一般是除一級界面以外的），則觸發注冊登錄流程。用戶完成注冊登錄之后，才可使用和操作絕大部分的功能。
本流程圖需要配合頁面交互原型理解。
五、關鍵頁面交互設計
登錄注冊體系將包含五個部分，主界面、驗證碼登錄/注冊、密碼登錄、忘記密碼和新用戶注冊，在實際流程操作中會根據用戶的選擇，和系統的判斷進行切換。賬戶體系的配套將會略過，以下是登錄注冊的頁面交互設計、設計考量和功能點介紹。
1.主界面
- 布局：主界面集合三種登錄方式，將微信登錄作為主方式。
- 前提：成功登錄的前提條件是必須先勾選同意用戶協議，否則報錯。
- 授權：第三方的登錄，點擊微信orQQ，授權成功后，即可登錄進入APP，自動獲取用戶的昵稱性別頭像信息填充社交頁。
2.驗證碼登錄/注冊
（1）設計解析
- 手機賬號登錄，考慮簡單又快速進行，突出驗證碼快速登錄/注冊，輔以密碼注冊。
- 密碼注冊的弊端是很容易忘記密碼，忘記之后，找回密碼流程也繁瑣。
- 驗證碼登錄，雖然對頻繁換手機的用戶是個噩耗，短信也有達到率的問題，但考慮到效率跟成本，特別在拉新環節，還是作為主方式。
其實基于驗證碼到達率和安全性，我考慮過換移動認證，就是手機號碼一鍵登錄，無需密碼跟驗證碼?？上嶋H接洽的時候行不通，而放棄了，文本會介紹下這個事情。
（2）設計點
- 驗證碼登錄：登錄注冊界面為驗證碼登錄，附以密碼登錄。
- 按鈕：登錄注冊的按鈕合二為一。也就是說，用戶不需要選擇是登錄還是注冊，將判斷交給了后臺。只要用戶的手機號碼還在，直接憑驗證碼進入即可。比起選擇密碼登錄之后忘記密碼，或者是干脆就不記得自己是否注冊過，在錯誤的界面輸入信息之后來回切換，二合一的方式更加友好，也是本次設計的一個亮點。
- 手機號碼：采用更加清晰的的3-4-4數值格式，輸入框末尾配清除按鈕，錯誤輸入后可一鍵清除。手機號碼輸入框也有記憶功能，可獲取前一次登錄的手機賬號，可以獲取同一次登錄注冊已填過的賬號信息。
- 驗證碼：手機號碼位數輸入正確類型和位數之后，才激活驗證碼功能。否則點擊會報錯。之后，驗證碼的激活以變色表現，這是個視覺指示。輸入完成第一行，人眼會自然而言的落在第二行的開頭，如無例外，用戶需要尋找一番，才會覺知過來，去點擊獲取驗證碼。
- 加載指示：數據傳輸到服務端，判斷對錯，再返回結果。這個流程費些時間，用加載小菊花，表示后臺正在處理，舒緩下等待的焦急。
3.密碼登錄
（1）設計解析
密碼登錄考慮到向后兼容，老用戶的賬號以密碼登錄；也是適應本期的新用戶注冊。
同時標配忘記密碼，也可切換新用戶注冊，或驗證碼登錄，這些元素的布置考慮，是基于流程的。
密碼的輸入，其實正如設置密碼，應該做格式限制。但是因為第一版沒限制，不清楚用戶設置了什么，所以此處不能輕易填坑。
數據輸入都該考慮下限制的，為什么？在給產品經理講技術這書里，要是你看到黑科技SQL注入攻擊也會很印象深刻的……
（2）流程
跟驗證碼的簡單路徑不一樣，密碼登錄因重在流程上邏輯自洽，更需配流程圖查看才好理解。
正常流程是：輸入手機號->輸入密碼->點擊登錄->登錄成功。
異常流程是：
- 輸入手機號->輸入密碼->點擊登錄->提醒“未注冊”->點擊新用戶注冊or返回上一級驗證碼登錄/注冊。
- 輸入手機號->輸入密碼->點擊登錄->提醒“賬號或密碼不對”->重新輸入or忘記密碼or驗證碼登錄。
4.忘記密碼
（1）設計解析
步驟：忘記密碼此處分兩步，一步驗證，一步設置。設置完之后，直接登錄進入APP，無需再重復密碼登錄的步驟。（記不住密碼更痛苦的事情是，忘記密碼剛找回來，在下一步重新登錄的時候又忘記了）。
異常流程：忘記密碼此處還有個異常流程，是該賬號不存在。有童鞋會說，正是密碼輸錯才會到來這界面，這么還會有賬號不存在的情況？對，情理上其實不大可能發生，但是程序邏輯上有這個可能，但是又無法通過前面的步驟過濾掉，是要補充下的。
此處判斷賬號不存在的提醒，是點擊獲取驗證碼之后，亮點之一。這里是考慮辛辛苦苦獲取驗證碼，填寫完畢之后才來告訴用戶賬號不存在，有些不厚道的……
（2）設計點：
驗證賬號：常規的做法，先驗證碼驗證手機號，再下一步設置密碼。
有些APP會將驗證賬號跟設置密碼放在同一個頁面，其實拆開會更清晰。而且，驗證手機號碼步驟復用率是很高的，比如，可以復用到推廣員更改綁定銀行卡時，作為賬號驗證。
設置密碼：密碼設置要限定格式，之后僅需輸入一次就可以直接登錄進入了。
重復兩次數據，再次校驗肯定更穩妥，但是登錄成本提高了，以我們用戶的耐心，我們的產品就沒必要承擔這個教育成本了。如果說擔心手誤輸錯了的，可以用驗證碼登錄的，再不濟可以用找回密碼的。但是大多數用戶其實只考慮本次能快點進入就好。
5.新用戶注冊
（1）設計解析
新用戶注冊界面近乎跟忘記密碼是一樣的流程，區別在點擊獲取驗證碼，此處的異常流程是該賬號已存在。此處設置優化的流程，判斷是已有賬號之后，會直接跳轉到驗證碼登錄/注冊界面處，直接獲取已填寫的手機號碼，驗證就行，對新用戶盡量友好。
經過前面的界面篩選，此處的賬號不存在的發生概率很少，但是作為關鍵流程而言，完整性是必要的。
?
移動認證
文內留個懸念要談談移動認證，移動認證是什么？最直接的體驗是，無需輸入任何數據，直接點擊授權就登錄。是不是很黑科技？！
但是為什么最終放棄了呢，請聽細講。
理想情況：
移動認證是運營商移動提供的，基于手機sim卡和移動網絡直接認證登錄的技術，米家、愛回收跟同花順應用在了自家APP里。當時上手體驗，驚艷，簡直零感登錄；況且移動官網也有免費的sdk，更是竊喜。以移動認證為主登錄的原型設計完畢，就立刻接洽移動認證sdk的接入。
現實情況：
但是呢，很快就被開發文檔打臉了，簡言之，就是層層篩選之下，能一鍵登錄的用戶遠沒有想象的多。
移動認證的原理是基于移動網絡通信的。首先基于sim卡識別本機號碼，在移動網絡開啟的前提下傳輸信息以授權通過，此時可順利登陸；但是如果沒開移動網絡，就沒轍了；如果WiFi跟移動網絡同開，以WiFi為主，那將強制占道先驗證再釋放WiFi。如果移動網絡通信不成，那就通過短信收發來完成數據傳輸。
所以，這么流氓的做法蘋果肯定是不樂意的；電信不參與；oppo的ROM不支持此流程……層層篩選下來，加上關閉移動網絡的，能順利使用的其實不多；而且，除非付費，否則移動認證的logo說明只能用官方的，簡直是給移動打廣告….這些阻力遠高于收益，所以，果斷放棄了，采取了本文講述的方案。
果然，合適的才是最好的。
本文由 @閱天 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels ，基于 CC0 協議
現在都能做到一鍵登錄了。作者文章是2018年寫的，內容非常全，前瞻性也很好，真不錯！
對，現在一鍵登錄已經很主流了。服務商提供的價格單次使用有時都比短信驗證碼要低了，安全性也不錯，可以盡情用了。
您好！想請教一下，在登錄的時候發現還未注冊然后跳轉注冊的話，關于“已輸入賬號記憶”和需要重新輸入的兩種情況使用場景和原因是什么??？
符合場景的話，一般是可記憶就記憶。
1.如果從未輸入，自然是空白的；
2.如果是之前輸入過，就獲取之前輸入的；
3.如果是有新的輸入，就覆蓋更新新的輸入；
4.如果是在登錄的時候，發現該手機號碼未注冊，從而轉去注冊界面，獲取之前輸入的號碼，也會方便很多。
最后一點會考慮說，可能用戶的號碼輸入不正確，但發生概率比較小，可以先默認獲取（有清除鍵可清除）。這個點比較細節。
移動認證的缺點感覺題主放大了；
1、ios是支持移動認證一鍵登錄；
2、電信號碼也支持一鍵登錄（ios情況下電信無法預取號，但也可以一鍵登錄的）
3、WiFi和4G同時開的情況，只有首次登錄無法成功；
4、說到授權頁面只允許放移動logo，其他第三方登陸騰訊/微信/微博/網易/百度/FB/Google+好像都是這樣的哦，這無可厚非吧
—-
手機號注冊的流程，能否考慮把手機號+密碼的方式舍棄掉呢
時隔一年，現在知道有付費產品的一鍵登錄的體驗會好很多，比如阿里云的跟創藍的，文中很多的觀點只針對于移動的免費服務，所以大家在實際用的時候，可以多看看不同的短信服務商。
手機注冊流程，可以將設置密碼的方式后置，用戶體驗會好很多的。
進入忘記密碼頁面后，為什么沒有直接獲取之前頁面填寫的數據？
學習了
1. 每次登錄，都要勾選同意協議，不太合適吧？
2. 忘記密碼，在哪里，沒找到。
3. 手機號+驗證碼，登錄與注冊對用戶來說操作上沒有任何差異，不明白為什么要標注為“登錄/注冊”，還口口聲聲說這是亮點？難道不是給用戶造成認知困難嗎？市場上基本上都是直接寫“登錄”或者“快捷登錄”，清晰告知用戶能登錄進入產品頁面，作者的處理怎么會是“亮點”呢？我覺得文案上要簡單、符合大家認知習慣。后臺判斷是新用戶（–記憶存檔）還是老用戶（–調取用戶數據）就好了。
4. 密碼登錄的，提醒“未注冊””->賬號或密碼不對，不懂為什么是這樣，賬號或密碼不對跟未注冊是兩回事呀。
5. 總的來說，還有優化空間。流程圖也看得很費勁。另外，可以畫個頁面跳轉流轉圖，更好理解一點。
1.每次登錄，都要勾選同意協議，很合適啊。產品本來就不能隨便替用戶做決定啊，特別是像這種可能會損害到用戶/產品利益的情況下。
2.密碼登錄作者明明寫了兩個異常情況啊：
①.輸入手機號->輸入密碼->點擊登錄->提醒“未注冊”->點擊新用戶注冊or返回上一級驗證碼登錄/注冊。
②.輸入手機號->輸入密碼->點擊登錄->提醒“賬號或密碼不對”->重新輸入or忘記密碼or驗證碼登錄。
“未注冊”跟“賬號和密碼不對”本來就是兩回事啊，所以未注冊就讓用戶去注冊，賬號和密碼不對就讓用戶重新輸入啊，很難理解嗎？
最近自家app也在做登錄注冊，現在基本已經做完，讀完后，發現做的邏輯很是相像，如果早發現這篇文章，會省不少功夫 ??
具體是哪個網站？
看得出來是用心了的。登錄注冊可以有更大的想象空間，指紋聲控虹膜解鎖也是一種方式。
這些要考慮硬件支持、成本效益等。指紋聲控虹膜解鎖有案例分享不，在APP應用層面的？
有1個疑問：
對于一直沒有設置過密碼的用戶（可能通過第三方或驗證碼登錄），什么時候需要引導設置密碼？
比如，有該類用戶可能忘記是否設置了登錄密碼，然后進入頁，輸入“登錄過的手機號”和“隨便一個密碼”后，下一步：是直接返回頁；還是Toast提示，然后進入流程？
你提到的是很多個的問題。
首先，對于大多數功能而言，第三方登錄跟手機賬號登錄是同等效果，這種情況下不需要引導；但是有些安全性高的環節，需要驗證賬號是本人或者要求手機賬號，也就是綁定或者是驗證手機。
對于手機賬號登錄注冊而言，密碼登錄跟驗證碼登錄是平行的兩個方法，不存在一定得要設置密碼的。需要密碼的場景考慮的是換手機或者是驗證碼收發遲滯。如果是用驗證碼方式登錄進來，需要更換手機，可以在找回密碼處設置密碼。
這個說的不正是人人都是產品經理PC端的登陸方式么哈哈？“第三方登錄+立刻綁定手機的方式，直接抵消了第三方登錄的便利，比直接手機號注冊更麻煩。而且，設計上，手機號注冊需要設置兩次密碼，密碼需要一致；設置之后，還得進入登錄界面，再次填寫賬號密碼，正確匹配才可以進入APP?！?/p>
對呀，這個很煩的，所以一定不會再用到自家APP上。
文章講了很多內容，但是最感興趣還是登錄注冊合一的亮點，我覺得這個是很可以的，對于已經注冊的用戶直接調取登錄的入口，對于未注冊的用戶直接調取注冊的入口，只是會增加一些后臺同學的校驗工作，另外還有就是對于很多APP，目前采用手勢指紋的更多一些，所以這一步亮點在某種程度上來講只是一個小亮點吧，只是個人意見，不喜勿噴。
很多APP是采用手勢指紋，舉出些例子吧。
我們的用戶并非是移動互聯網的深度用戶，所以基本是 在常規的方式上做優化是最合適的。
有個疑問，為什么點擊 忘記密碼 前一步 不能去明確判斷 是賬號不存在 還是 密碼錯誤，那如果賬號不存在的話 就直接toast提示 然后讓用戶選擇 手機號密碼登陸 或者 新用戶注冊就可以。如果是密碼錯誤 就直接重置密碼
密碼登錄處賬號密碼校驗不一致，其實出錯的不是兩種情況，而是三種情況。
第一個是賬號未注冊，這個已經提醒了，因為有兩種方式可以注冊，返回上一步驗證碼注冊和新用戶密碼方式注冊，所以此處留給用戶來選擇；
第二種是賬號正確，密碼錯誤，這個就是用戶輸錯密碼了，去找回密碼就可以；
第三種是很多人會忽略掉的，用戶賬號輸錯了，這個不論是輸錯了是未注冊和還是僥幸輸入了正確的已注冊的賬號，將正確的密碼一輸入，還是會報錯，這時候是應該怎么提醒呢？其實判斷不了用戶輸錯賬號的情況，設置的提醒也不能誤導用戶。所以，提醒賬號或者密碼錯誤，而不替用戶做決定是合適的。
嗯 對第三種我的確有忽略了，感謝耐心解答~謝謝！
流程圖看不清呀，老哥可以換一個高清的嘛
另存圖片，用圖片編輯器查看就能放大了
登錄注冊安全防護這塊作者是怎么考慮的啊 比如有些程序自動注冊、短信轟炸或自動登錄破解密碼
1.安全防護這方面在產品設計上可規避的并不多，比如傳輸給服務端的數據（賬號秘密等）采取字符類型跟長度的限制以防止SQL注入攻擊，在關鍵的環節要求綁定手機，驗證碼驗證手機賬號為本人。其實更多的是在技術實現上，標注好安全等級一些總要求，然后放心交給技術童靴來完成。
2.登錄注冊上會涉及到加密設計，在往服務端傳輸之前，給密碼做哈希和加鹽生成面無全非不可逆推的字符串，然后再傳輸，這個可以保證在傳輸過程中的數據安全性。服務端校驗密碼賬號一致之后，就會給客服端下方憑證，客戶端在有效期（一般一個月）內根據憑證校驗就好，自動登錄過程已經不涉及密碼。憑證過期之后，再來一次第2步驟就是了。
3.短信轟炸如果不是運營設定的，那就是基站跟手機通信協議的欠缺造成的，偽基站問題，在APP層面是解決不了的。
程序自動注冊是指什么情況？有些工具型APP確實不需要登錄注冊，給本地分配個id就可以用了的。
手機號碼 3-3-4 。作者做的不是國內的產品 ？
筆誤，感謝指正。
把注冊和登錄按鈕合一，看似是讓用戶的操作簡單了，實則會讓用戶困惑，目前通用的還是分開，這樣是比較明確的，個人意見，僅供討論~
不考慮下弱化注冊，實現注冊和登錄的功能性合一？美滋滋…
注冊和登錄兩者的合并會產生很多的問題，個人覺得這點不妥~注冊屬于一次性使用，不是高頻操作~
合并具體會有什么問題？
有時候不記得自己是否注冊過，這種情況下選擇手機登錄或注冊都是50%的成功概率，選錯了要來回切換是很不方便的。
如果僅是針對這個問題，我倒覺得這樣會更好：在登錄時輸入手機號后，判斷，若沒有注冊，則可以提供跳到注冊頁面的入口。注冊和登錄按鈕合并，使得整個流程具有不可預知性，導致用戶困惑~另外，要明確產品的主流用戶到底是誰？
導致整個流程有不可預知性，有說法的話可以再具體說明下。
導致用戶迷惑這點倒不會，用戶只想順利進入APP做他想要的操作而已，至于是登錄還是注冊，他并不關心。如果之前注冊過，還給他原來的賬戶數據就可以了。
所以我說考慮弱化注冊，目前我改版的2款APP，沒有因此出現任何問題， 且客服少了一些單子。 我蠻推崇的， 有興趣可以聊一聊。
弱化注冊，我是贊成的~
吧需要用戶判斷的內容修改為系統判斷，只需一步一步的往下走，為啥需要注冊？只有登錄，老用戶登錄和新用戶登錄，對于用戶來說只是登錄
那你覺得為啥現在還要區分注冊和登錄呢？為啥不直接把注冊去掉呢？從用戶角度來看，還是要讓用戶感知自己是在注冊還是登錄的，不然會很疑惑的~
舊的存在不一定代表是對的；在以前，注冊的存在，更多是為了讓用戶對賬號有記憶，pc時代手機并非人人都有，讓用戶每次都通過綁定的郵箱發送校驗鏈接登錄也不現實（被屏蔽、操作流程跳出等）；但進入移動時代，手機+驗證碼的方式成為主流，一方面是手機普及，資費降低；另一方面，密碼的記憶成本相對變高了，通過手機+驗證碼的方式反而更能縮短流程； 再說回，用戶注冊的直接目的不是注冊本身，而是登錄；既然有更便捷的注冊方式（弱化注冊）我覺得是可以考慮的
“比如長度正確，但是數字不是手機號碼”這種情況怎么判斷出來手機號碼數字（非字母）不是正確的手機號碼??？
例如：125-5858-8585，這個怎么判斷不是正確手機號碼？用短信供應商的接口嗎？求解答？
號碼校驗，目前有成熟的插件可以直接拿來用， 你說的這些問題已經不是什么障礙了。
產品小白，說個不成熟的想法?？刹豢梢赃@樣，當用戶輸入手機號碼＞獲取驗證碼＞系統判斷是否為已有賬戶。是＞進入主頁，否＞直接跳轉安全協議＞勾選＞成為新用戶。。。此時的新用戶未設置密碼，在主頁進行提醒，引導用戶設置密碼。
這樣的話是不是讓用戶的操作步驟減少許多？
請指教下可行性。
在本文方案，驗證碼驗證登錄/注冊的流程上，如果是判斷為否（新用戶），無需設置密碼，也是直接進入主頁的。后臺會獲取否的情況，判定為新用戶，注冊賬號。這個步驟已是優化了。
你提及的判斷為新用戶老用戶，去不同的界面操作，是在密碼登錄的環節。其實已經經過兩道篩選（第三方登錄、驗證碼快捷登錄），到達這個界面的用戶已經很少了，但是為了兼容老版本的情況，是必須補全相關的流程，只是在指引的時候，會有傾向性。
是個不錯的想法，不過跳轉協議前，最好給予用戶一個明確的注冊提示
其實你還沒理解登錄/注冊一體的設計考量點在哪里
感覺 登錄/注冊一體的設計 就是弱化了注冊，不知不覺就進來了。。
恩，是的
那要看什么產品，有些產品，登錄注冊需要分開，而且要能夠清楚明白的表達給用戶——這是登錄，這是注冊。但是如果你通過數據反饋，發覺說很多用戶是注冊過了，但是太久沒用了，可以使用登錄注冊一體化。其實分開加合并兩個一起用是最好的，有些用戶就是想手機號注冊，方便快捷，如果不分開，用戶就需要去找這個功能，而對于忘記是否注冊過的用戶而言，他可以在注冊和登錄那里隨便試，我們后臺自動判斷
有個疑問，為什么【點擊登陸方式】后需要進行【協議的勾選】呢？
一般登陸流程里是不涉及到協議部分的吧，進行賬號注冊的時候才需要確認勾選
這個是不同產品的設計考慮了，有許多確實是只放在手機號碼注冊環節。
至于為什么放在這里，是有兩點考慮。
第一，流程圖雖然寫的是點擊登錄，其實他是登錄/注冊，是填寫手機號碼之后才判定是新老用戶，新注冊必須遵守用戶協議，放在這里是合適的；
第二，難道第三方登錄的用戶不需要遵守用戶協議么？要的。既然要的話，為什么不放在一開始的總頁面里？
1、你這里的用戶協議，全程是“用戶注冊協議”
2、第三方登錄在用戶層面并沒有“協議”這個概念，只有“授權”，本質上只是借用其他平臺的賬號在自己的賬號體系下建了一個用戶；
3、可以參考剛剛那個產品小白兄弟的評論，他是放在自有賬號體系下的手機登錄里放上協議勾選，而不是放在更上一層的、包括第三方登錄的地方，我覺得這是更準確一點的
用戶協議不一定是用戶注冊協議，可以是用戶服務協議、平臺服務協議，用戶隱私協議等說明用戶權利跟義務、平臺提供的服務的文件和條款，原則上是所有進入APP的用戶都要遵守的規范。既然是所有的用戶，那么第三方登錄只是快速登錄（or注冊的方法）的一種方法，不同注冊方式并不享在這類型的平臺條款上有什么特殊的權力跟義務。
很詳細，有亮點，發現需要提示給用戶的東西太多了，之前確實沒注意，感謝
嗯嗯，常規的地方也有可優化的地方。
講解的非常詳細。
受教了，謝謝