移動信號的強弱對掃碼支付有影響嗎？

肯定會有影響。

接下來就是對于這個服務的詳細實現。首先，大概說一下原理：用戶打開網站的登錄頁面的時候，向瀏覽器的服務器發送獲取登錄二維碼的請求。服務器收到請求后，隨機生成一個uuid，將這個id作為key值存入redis服務器，同時設置一個過期時間，再過期后，用戶登錄二維碼需要進行刷新重新獲取。同時，將這個key值和本公司的驗證字符串合在一起，通過二維碼生成接口，生成一個二維碼的圖片（二維碼生成，網上有很多現成的接口和源碼，這里不再介紹。）然后，將二維碼圖片和uuid一起返回給用戶瀏覽器。

瀏覽器拿到二維碼和uuid后，會每隔一秒向瀏覽器發送一次，登錄是否成功的請求。請求中攜帶有uuid作為當前頁面的標識符。這里有的同學就會奇怪了，服務器只存了個uuid在redis中作為key值，怎么會有用戶的id信息呢？

這里確實會有用戶的id信息，這個id信息是由手機服務器存入redis中的。具體操作如下：

手機端+服務器

話說，瀏覽器拿到二維碼后，將二維碼展示到網頁上，并給用戶一個提示：請掏出您的手機，打開掃一掃進行登錄。用戶拿出手機掃描二維碼，就可以得到一個驗證信息和一個uuid（掃描二維碼獲取字符串的功能在網上同樣有很多demo，這里就不詳細介紹了）。由于手機端已經進行過了登錄，在訪問手機端的服務器的時候，參數中都回攜帶一個用戶的token，手機端服務器可以從中解析到用戶的userId（這里從token中取值而不是手機端直接傳userid是為了安全，直接傳userid可能會被截獲和修改，token是加密的，被修改的風險會小很多）。手機端將解析到的數據和用戶token一起作為參數，向服務器發送驗證登錄請求（這里的服務器是手機服務器，手機端的服務器跟網頁端服務器不是同一臺服務器）。服務器收到請求后，首先對比參數中的驗證信息，確定是否為用戶登錄請求接口。如果是，返回一個確認信息給手機端。

手機端收到返回后，將登錄確認框顯示給用戶（防止用戶誤操作，同時使登錄更加人性化）。用戶確認是進行的登錄操作后，手機再次發送請求。服務器拿到uuId和userId后，將用戶的userid作為value值存入redis中以uuid作為key的鍵值對中。

登錄成功

然后，瀏覽器再次發送請求的時候，瀏覽器端的服務器就可以得到一個用戶Id，并調用登錄的方法，聲成一個瀏覽器端的token，再瀏覽器再次發送請求的時候，將用戶信息返回給瀏覽器，登錄成功。這里存儲用戶id而不是直接存儲用戶信息是因為，手機端的用戶信息，不一定是和瀏覽器端的用戶信息完全一致。

如果網絡不好，手機與服務器傳輸的數據就會受到很大影響，從而導致掃碼速度慢，或者掃碼失敗。