登入是一項核心基礎功能，通過登入對使用者進行唯一標識，繼而才可以提供各種跟蹤服務，如收藏、下單、留言、訊息、釋出、個性化推薦等。小程式功能的方方面面大多會直接/間接涉及登入，因而，登入功能健壯與否高效與否是值得重點關注與保障的。

登入涉及的面比較多：觸發場景上，各種頁面各種互動路徑都可能觸發登入；互動過程上，既需要使用者提供/證明id，也需要後端記錄維護，還需要保證安全性；複用場景上，既是通用功能，需要多場景多頁面甚至多小程式複用，又是定製功能，需要各場景/頁面/小程式區分處理。要做到各種情形下都有良好的互動體驗，且健壯、高效、可複用、可擴充套件、可維護，還是相對比較複雜的。

本文將探討小程式登入過程中的一些主要需求和問題，以漸進迭代的方式提出並實現一個健壯、高效的登入方案。

順帶一提，es6語法中的async/await、Promise、decorator等特性對於複雜時序處理相當有增益，在本文中也會有所體現。

基礎流程

如上圖所示，基礎登入流程為：

• 呼叫微信登入介面wx.login獲取微信登入態
• 呼叫微信使用者資訊介面wx.getUserInfo獲取微信使用者資訊
• 呼叫後端登入介面，根據微信使用者標識及資訊，記錄維護自己的使用者體系

該流程主要基於以下考慮：

• 互動上，使用者只需在微信的授權彈窗上點選確認，不需要輸入賬號密碼等複雜操作；
• 體驗上，可以直接獲取微信暱稱頭像等作為初始使用者資訊，使用起來更親切，傳播時好友辨識度也更高；
• 開發上，可以直接使用或對映微信使用者標識，無需自己進行標識的生成和驗證；
• 安全上，微信已經在使用者資訊的獲取、傳輸、解密等環節做了許多處理，安全性相對有保障。

健壯流程

拒絕授權問題

問題：

獲取微信使用者資訊時，會出現一個授權彈窗，需要使用者點選“允許”才能正常獲取； 若使用者點選“拒絕”，不僅當次登入會失敗，一定時間內後續登入也會失敗，因為短期內再次呼叫微信使用者資訊介面時，微信不會再向使用者展示授權彈窗，而是直接按失敗返回。 這樣導致使用者只要拒絕過一次，即使後來對小程式感興趣了願意授權了，也難以再次操作。

方案：

如上圖所示，增加以下流程以處理拒絕授權問題：

• 獲取微信使用者資訊失敗時，判斷是否近期內拒絕授權導致；
• 若為拒絕授權導致，則提示並開啟許可權面板，供使用者再次操作；
• 若使用者依然未授權，則本次登入失敗，否則繼續後續流程。

這樣，使用者拒絕授權只會影響本次登入，不至於無法進行下次嘗試。

登入態過期問題

問題：

• 微信登入態有效期不可控 上圖截自微信官方文件，從中可以看出：
  • 後端session_key隨時可能失效，什麼時候失效開發者不可控；
  • 要保證呼叫介面時後端session_key不失效，只能在每次呼叫前先使用wx.checkSession檢查有效期或直接重新執行微信登入介面；
  • 前端不能隨便重新執行微信登入介面，可能導致正在進行的其它後端任務session_key失效；此外，實踐中發現，wx.checkSession平均耗時約需200ms，每次介面呼叫前都先檢查一遍，開銷還是蠻大的。如何既保證介面功能正確有效，又不用每次耗費高額的查詢開銷，成為了一個問題。
• 後端登入態過期 後端自身的登入態有效期也存在類似的問題，有可能在呼叫介面時才發現後端登入態已過期。

方案：

如上圖所示，增加以下流程以處理登入態過期問題：

• 呼叫資料介面時顯式指明是否需要登入態，若需要則在介面呼叫前後自動加入登入態校驗邏輯；
• 介面呼叫前只校驗前端登入態，不校驗後端登入態，也不校驗微信登入態，以節省每次校驗開銷；
• 介面呼叫後校驗後端及微信登入態，若後端返回登入態相關錯誤碼，則重置前端登入態、重新登入、重新呼叫資料介面。

這樣，只有在真正需要重新登入的時候（無前端登入態/後端登入態失效/後端被提示微信登入態失效）才會重新執行登入流程；並且，一旦需要重新登入，就會自動重新觸發登入流程。

併發問題

問題：

如上圖所示，頁面各元件各功能有可能同時觸發登入流程，可能會導致：

• 額外效能開銷，登入流程重複進行，登入介面重複呼叫；
• 體驗問題，連續多次彈窗，影響使用者互動；
• 邏輯問題，後一次登入重新整理了前一次登入的session_key，導致前一次登入介面解碼失敗，返回異常結果。

方案：

如上圖所示，加入免併發邏輯：若登入流程正在進行，則不重複觸發登入流程，而是加入當前流程的監聽佇列，待登入結束時再一併處理。這樣，任一時刻最多隻有一個登入流程正在進行。

流程實現

時序控制

如上圖所示，目前登入流程已較為複雜，步驟較多，且大多是非同步操作，每步成功失敗需要區分處理，處理過程又會相互交織。如果直接在微信介面/網路介面提供的success/fail回撥中進行邏輯處理，會造成：

• 回撥層層巢狀，影響程式碼書寫和閱讀；
• 不同路徑公共步驟難以統一提取；
• 時序邏輯不直觀，不易管理。

因而採用Promise+async/await進行時序管理：

• 將每個步驟Promise化： JavaScript class Login { static _loginSteps = { //各登入步驟 /** * 微信登入：呼叫微信相關API，獲取使用者標識（openid，某些情況下也能獲得unionid） * <a href='http://www.jobbole.com/members/wx1409399284'>@return</a> {Promise<Object>} 微信使用者標識 */ wxLogin(){ return new Promise((resolve,reject)=>{ //結果以Promise形式返回 wx.login({ success(res){ resolve(Object.assign(res, {succeeded: true})); //成功失敗都resolve，並通過succeeded欄位區分 }, fail(res){ resolve(Object.assign(res, {succeeded: false})); //成功失敗都resolve，並通過succeeded欄位區分 }, }) }); }, /** * 獲取微信使用者資訊：呼叫微信相關API，請求使用者授權訪問個人資訊 * <a href='http://www.jobbole.com/members/wx1409399284'>@return</a> {Promise<Object>} 微信使用者資訊 */ requestUserInfo(){ return new Promise((resolve,reject)=>{ //結果以Promise形式返回 //... }); }, //... } }

  123456789101112131415161718192021222324252627282930

  classLogin{static_loginSteps={//各登入步驟/**     * 微信登入：呼叫微信相關API，獲取使用者標識（openid，某些情況下也能獲得unionid）     * <a href='http://www.jobbole.com/members/wx1409399284'>@return</a> {Promise<Object>} 微信使用者標識     */wxLogin(){returnnewPromise((resolve,reject)=>{//結果以Promise形式返回wx.login({success(res){resolve(Object.assign(res,{succeeded:true}));//成功失敗都resolve，並通過succeeded欄位區分},fail(res){resolve(Object.assign(res,{succeeded:false}));//成功失敗都resolve，並通過succeeded欄位區分},})});},/**     * 獲取微信使用者資訊：呼叫微信相關API，請求使用者授權訪問個人資訊     * <a href='http://www.jobbole.com/members/wx1409399284'>@return</a> {Promise<Object>} 微信使用者資訊     */requestUserInfo(){returnnewPromise((resolve,reject)=>{//結果以Promise形式返回//... });},//...}}

• 使用async/await管理整體時序： JavaScript class Login { static async _login(){ //管理整體時序 //.... let steps = Login._loginSteps; //微信登入 let wxLoginRes = await steps.wxLogin(); if (!wxLoginRes.succeeded) //微信登入介面異常，登入失敗 return { code: -1}; //獲取微信使用者資訊 let userInfoRes = await steps.requestUserInfo(); if (!userInfoRes.succeeded && userInfoRes.failType==='userDeny'){ //使用者近期內曾經拒絕授權導致獲取資訊失敗 await steps.tipAuth(); //提示授權 let settingRes = await steps.openSetting(); //開啟許可權面板 if (!settingRes.succeeded) //使用者依然拒絕授權，登入失敗 return {code: -2}; userInfoRes = await steps.requestUserInfo(); //使用者同意授權，重新獲取使用者資訊 } if (!userInfoRes.succeeded) //其它原因導致的獲取使用者資訊失敗 return {code: -3}; //獲取使用者資訊成功，進行後續流程 //.... } }

  123456789101112131415161718192021222324252627282930

  classLogin{staticasync _login(){//管理整體時序//....let steps=Login._loginSteps;//微信登入let wxLoginRes=await steps.wxLogin();if(!wxLoginRes.succeeded)//微信登入介面異常，登入失敗return{code:-1};//獲取微信使用者資訊let userInfoRes=await steps.requestUserInfo();if(!userInfoRes.succeeded&&userInfoRes.failType==='userDeny'){//使用者近期內曾經拒絕授權導致獲取資訊失敗await steps.tipAuth();//提示授權let settingRes=await steps.openSetting();//開啟許可權面板if(!settingRes.succeeded)//使用者依然拒絕授權，登入失敗return{code:-2};userInfoRes=await steps.requestUserInfo();//使用者同意授權，重新獲取使用者資訊}if(!userInfoRes.succeeded)//其它原因導致的獲取使用者資訊失敗return{code:-3};//獲取使用者資訊成功，進行後續流程//....}}

如以上程式碼所示，微信登入、獲取微信使用者資訊、提示授權、開啟許可權面板等每一步都是非同步操作，都要等待success/fail回撥才能獲得操作結果併發起下一個操作；但利用Promise+async/await，可以像普通流程一樣，將這些操作線性組合，順序處理。 這樣，就可以實現直觀清晰的時序管理了。

過期處理

如以上程式碼所示，單獨封裝一個requestWithLogin函式，在資料請求前後加入登入態處理邏輯，可以保證資料請求會在有後端登入態時被髮送/重新發送。 並且，重新登入過程對資料介面呼叫方是完全透明的，呼叫方只需要知道自己的介面需不需要登入態，而無需進行任何登入態相關判斷處理，重登入過程也不會對介面呼叫返回結果造成任何影響。 這樣，就可以實現登入態過期自動重新登入了。

併發控制

如以上程式碼所示，利用Promise可以被多次then/catch的特性（亦即，一個async函式呼叫結果可以被await多次），可以使用一個Promise來記錄當前登入流程，後續呼叫直接對該Promise進行監聽。 這樣，就可以實現登入流程免併發了。

至此，我們就得到了一個功能可用、相對健壯、相對高效的登入模組。但依然還是存在優化空間的。

場景優化

二次授權問題

問題： 使用者同意授權後，小程式可以訪問到微信使用者資訊，並且一段時間內再次訪問時，也不會重新出現授權彈窗； 但是，如果使用者長時間未使用小程式，或將小程式刪除重進，則登入時會再次出現授權彈窗。 一方面會對使用者造成干擾，影響其瀏覽效率；另一方面，不利於流失使用者召回。

方案： 再次授權場景其實並不是很必要：

• 使用者第一次授權時，開發者已經可以獲得使用者暱稱、頭像等使用者資訊和openid、unionid等使用者標識；
• 再次授權時，雖然使用者資訊可能有更新，但完全可以等使用者進個人主頁/編輯資訊時再進行同步，沒必要剛進小程式就彈窗；
• 再次授權時，使用者標識並不會變化；
• 只調用微信登入介面，不觸發授權，已經可以獲得openid了，通過openid就可以從資料庫中查詢使用其上次授權時的使用者資訊和unionid等其它使用者標識。

因而，增加以下流程以優化二次授權場景：

如上圖所示，在微信登入介面呼叫成功之後，先嚐試直接根據openid完成登入過程，若失敗再去請求使用者授權。

這樣，只有新使用者才會出現授權彈窗；老使用者、迴歸使用者，都可以直接靜默完成登入過程。

場景適配問題

問題： 不同場景對登入行為可能有不同的期望：

• 有些場景，希望只在需要時自動登入，如商品詳情頁，希望在使用者點選留言、收藏等按鈕時自動調起登入並完成留言、收藏等相應操作；
• 有些場景，希望只嘗試靜默登入，如首頁，希望對使用者做個性化推薦和針對性投放，但又不願彈窗阻撓使用者；
• 有些場景，希望保證前後端登入態一致，如微信介面資料解碼。

單一的登入流程很難滿足這種多元的場景需求。

方案： 呼叫登入/要求登入的資料介面時支援指定場景模式：

如上圖所示，登入流程支援指定不同場景模式：

• 通用模式，為預設模式，會自動調起登入並完成相應資料請求和後續操作；
• 靜默模式，只會嘗試靜默登入，不會嘗試授權登入，成功與否均不影響頁面功能和後續介面呼叫；
• 強制模式，會重新登入，不管前端是否保有登入態，以保證前後端登入態同步。

實現

場景優化方案主要是增加了一些流程&判斷，使用上文中的“時序控制”基本可以解決。 主要難點在於，上文中的免併發機制不再適用。比如，靜默模式正在進行時又觸發了一個強制模式的請求，此時，應觸發授權彈窗正常登入而不是監聽使用靜默模式的登入結果。 如果拆成每個模式各自免併發，一方面，登入流程需重複書寫，不便複用；另一方面，模式之間併發也存在風險。 因而，引入公共步驟併合機制：