在互聯網應用開發中，登錄功能看似簡單，實則暗藏諸多挑戰。許多項目初期僅支持手機號登錄，但隨著業務發展，產品需求不斷變化，陸續要求增加微信、QQ、微博、Apple ID、郵箱等多種登錄方式。每新增一種登錄方式，開發團隊就不得不新建數據表、重寫相關邏輯，導致登錄相關的數據表迅速膨脹，代碼維護難度大幅增加，修改通用邏輯時稍有不慎就會引發各種問題。
早期常見的手機號登錄設計，采用手機號加密碼注冊的方式，用戶需完成輸入手機號、接收驗證碼、填寫驗證碼、設置密碼、填寫用戶名等一系列步驟才能注冊成功，之后才能登錄。這種方案存在明顯弊端，一方面注冊流程繁瑣，用戶中途流失的可能性較大；另一方面密碼容易遺忘，用戶找回密碼的體驗較差。為改善這些問題，有團隊進行了優化，弱化密碼的作用，改為手機號加驗證碼直接登錄。新用戶首次使用手機號和驗證碼登錄時，系統自動創建賬號，不強制要求填寫用戶名和密碼，用戶后續可根據需求自行設置密碼，也可一直使用驗證碼登錄。如此一來，注冊和登錄流程合并，用戶體驗得到顯著提升。
然而，當需要增加第三方登錄方式時，新的問題接踵而至。以增加微博登錄為例，開發團隊新建了“微博用戶信息表”，用于存儲微博的 openId、access_token、用戶昵稱、頭像等信息，并與自身用戶表建立關聯。隨著 QQ、微信、Apple ID 等開放登錄功能的相繼推出，類似的表不斷新建，每種登錄方式都有獨立的一套邏輯，代碼重復率極高。修改通用邏輯時，需要在多個地方同步操作，一旦遺漏就可能導致 bug 出現，這種狀況顯然難以持續。
為解決上述問題，開發團隊進行了關鍵轉變，將“登錄方式”從用戶表中剝離出來。經過深入分析發現，所有登錄方式本質上都具有統一的結構，即用戶信息加密碼（憑證）。例如，手機號登錄的用戶信息是手機號，密碼是用戶設置的密碼或驗證碼；微信登錄的用戶信息是微信的 openId，密碼是 access_token；郵箱登錄的用戶信息是郵箱地址，密碼是用戶設置的密碼?；谶@一發現，團隊將數據表拆分為兩張：用戶基礎信息表（users）和用戶授權信息表（user_auth）。用戶基礎信息表僅存儲昵稱、頭像、性別、注冊時間等與登錄無關的基本信息，若要存儲手機號、郵箱等，僅作為展示用途，與登錄邏輯無關；用戶授權信息表則存儲所有與登錄相關的信息，核心字段包括 login_type（登錄類型，如 phone、email、weixin、weibo、qq）、identifier（該類型下的唯一標識，如手機號、郵箱地址、微信 openId）、credential（憑證，如密碼的哈希值、第三方的 access_token）。兩張表通過 user_id 關聯，一個用戶可對應多條授權記錄，每條記錄代表一種登錄方式。
這種設計帶來了諸多便利。以新增微信登錄為例，無需新建表和編寫新邏輯，只需在 user_auth 表中插入一條 login_type = 'weixin' 的記錄，查詢邏輯可完全復用。新增 Apple ID 登錄亦是如此。若一個用戶要綁定多個微信號，user_auth 表天然支持，一個 user_id 可對應多條 login_type = 'weixin' 的記錄，若業務層需要限制只能綁定一個，添加相應判斷即可。通過在 user_auth 表中添加 last_login_at 和 last_login_ip 字段，還能追蹤各種登錄方式的使用情況，例如了解某個用戶的微博登錄已多久未使用、某個微信號綁定了多長時間等。在密碼管理方面，以往用戶有手機號登錄和郵箱登錄兩種方式時，修改密碼需在兩個地方操作，容易遺漏，如今所有憑證都集中在 user_auth 表中，修改密碼只需更新對應記錄的 credential 字段，保證了數據的一致性。這種設計的最大優勢在于，登錄類型可無限擴展，且擴展成本極低。
在此基礎上，登錄功能進一步進化到一鍵登錄。手機號加驗證碼的登錄方式體驗雖已不錯，但整個流程仍需用戶輸入手機號、等待短信、輸入驗證碼，耗時約 20 秒。一鍵登錄則實現了更快登錄，其原理是運營商知曉用戶當前手機卡的號碼，可通過 SDK 直接獲取。用戶點擊登錄按鈕后，SDK 向運營商獲取當前號碼的 token，服務端再拿此 token 向運營商換取真實手機號，直接用該號碼完成用戶登錄，整個過程用戶無需填寫任何信息，登錄流程從 20 秒壓縮至 2 秒左右，且不依賴短信網絡，也避免了驗證碼被截獲的風險。具體流程為：App 初始化運營商 SDK，傳入 AppKey 和 AppSecret；用戶點擊“一鍵登錄”，SDK 向運營商發起請求，獲取當前號碼的 token；客戶端將 token 發送至服務端；服務端拿 token 調用運營商接口，換取真實手機號；用該手機號完成登錄或注冊。用戶只需點擊按鈕，即可快速完成登錄。
這套賬號體系設計并不復雜，核心在于將“用戶是誰”和“用什么方式登錄”分別存儲在兩張表中。在項目設計初期多思考一步，后續擴展時就能減少大量代碼修改工作。登錄作為基礎模塊，設計合理后基本無需頻繁變動，能夠穩定支撐業務運行較長時間。若項目仍在采用“每種登錄方式一張表”的老方案，建議盡早考慮遷移，且遷移越早，成本越低。
