在互联网应用开发中，登录功能看似简单，实则暗藏诸多挑战。许多项目初期仅支持手机号登录，但随着业务发展，产品需求不断变化，陆续要求增加微信、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 调用运营商接口，换取真实手机号；用该手机号完成登录或注册。用户只需点击按钮，即可快速完成登录。
这套账号体系设计并不复杂，核心在于将“用户是谁”和“用什么方式登录”分别存储在两张表中。在项目设计初期多思考一步，后续扩展时就能减少大量代码修改工作。登录作为基础模块，设计合理后基本无需频繁变动，能够稳定支撑业务运行较长时间。若项目仍在采用“每种登录方式一张表”的老方案，建议尽早考虑迁移，且迁移越早，成本越低。
