作者：雨飛
一、問題引入
在設計用於管理社團信息的網頁端時，我們需要解決的一個問題是怎樣讓社團管理員很方便地登錄到管理平台中去。出於提高用戶體驗角度的考慮，我們的小程序在用戶第一次登錄時，只需要微信授權獲得身份信息，就可以自動完成注冊和登錄流程，用戶無需手動輸入密碼或創建新的賬號，一切都是與微信綁定的。這種做法固然方便，但缺點在於登錄流程和微信環境高度綁定，脫離微信環境之后再想獲取並驗證用戶的身份信息就比較困難。
最后我們選擇了在網頁端設置小程序掃碼登錄，用戶只需要打開我們的小程序，在“我的”頁面中點擊“掃描二維碼”，便可以自動登錄到網頁端社團數據管理平台。在實現這個功能的過程中，我們遇到了一些問題，這些問題在經歷了一段時間的學習研究之后得以解決，我們覺得有必要在此把解決問題的過程記錄下來，作為技術博客。因此有了這篇文章。
二、幾個難題
1. 網頁端是怎么知道哪個用戶掃描的二維碼？
這是很多人在第一次看到”掃碼登錄“這種登錄方式時的第一反應。的確，這個過程看起來有點神奇，網頁上只是顯示了一個二維碼而已，為什么小程序掃碼之后，網頁端就知道是哪個用戶掃描的二維碼呢？如果我們要自己去實現這個功能的話，也必然面臨着同樣的問題。
2. 小程序掃碼，掃出來的是什么東西？
第二個問題實際上是由第一個問題引出的。既然網頁端不需要任何額外信息就能知道是哪個用戶掃描的二維碼，那么二維碼里就必然包含着對識別用戶身份至關重要的信息。這里面的信息具體有哪些內容？這也是我們着重要解決的事情。
3. 小程序掃到二維碼以后，做了什么事情，怎么和網頁端通訊的？
從用戶體驗的角度來看，小程序掃碼登錄是一件十分自然的事情：網頁端顯示二維碼，小程序掃碼，網頁端便可以正常登錄。然而小程序掃碼之后，網頁端怎么知道小程序已經掃碼了？小程序是如何把自身存儲的用戶信息發送給網頁端的？只有解決這些問題，掃碼登錄的流程才可以說是被真正打通。
三、解決方案
1. 至關重要的uuid
uuid（通用唯一識別碼）是解決以上難題的關鍵。其實掃碼登錄的根本難題在於如何在小程序和網頁端之間共享用戶的身份信息，因此勢必需要一個識別碼來進行網頁端和小程序的通信綁定。
后端服務器對外提供一個接口，網頁端每次訪問這個接口，都會獲得一個全局唯一的uuid。網頁端獲取uuid之后，將其轉換為二維碼展示在頁面上，二維碼包含且只包含這個uuid。
我們使用了qrcode.react作為網頁端生成二維碼的組件。
2. 用戶信息與uuid的綁定
后端服務器生成uuid之后，便會將這個uuid存入redis緩存中。小程序掃描到帶有uuid信息的二維碼，獲得用戶身份信息之后，訪問服務器的另一個接口，將用戶信息和uuid一起發送給后端。后端把身份信息與剛剛存入redis的uuid綁定在一起，由此完成用戶信息和uuid（也即二維碼）的綁定。
3. 網頁端輪詢uuid，直至獲取到用戶身份信息
網頁端知道，在未來的某一時刻，小程序會把當前登錄用戶的身份信息和uuid綁定在一起，因此網頁端只需要不斷輪詢后端服務器，並把自己的uuid作為參數，就可以知道uuid是否已經綁定了用戶信息。如果還未綁定，則等待直至uuid失效；如果已綁定，就使用該身份信息登錄。至此，掃碼登錄的流程全部打通。
四、一些技術細節
- redis在存儲uuid時，出於安全考慮，必須設置過期時間
- 網頁端輪詢時，需要注意輪詢時間間隔，避免對服務器造成過大壓力
- uuid一旦與用戶身份信息綁定，一次使用后則需失效，否則會帶來安全隱患