之后 , 后台判断是邮箱 , 手机号或是用户名 , 再根据条件查询是否为特定用户 ;
这个表结构能够承载未来一段时间的业务需求了 , 如果说某天冒出了一个新的登录方式 , 比如身份证号登录 , 怎么办...+密码的形式 , 用户信息即第三方系统中的 ID (第三方登录一定会给一个在他们系统中的唯一标识) , 密码即 access_token , 只不过是一种有使用时效定期修改的密码 ; 所以我们把它抽象出了用户基础信息表加上用户授权信息表的形式...(解决办法是在代码里加一个限制 , 至少保留一条user_auths的记录) ;
如果你非得得到用户的邮箱 , 那么每次登录的时候看到他不存在一条 identify_type 为 email 的记录...如果你说邮箱和手机号就是用户信息的组成部分 , 他们依然需要体现在 users 表中作为前端展示?...用户同时存在邮箱 , 用户名 , 手机号等多种站内登录方式时 , 改密码时必须一起改 , 否则就变成了 邮箱 + 新密码 , 手机号 + 旧密码访问了 , 肯定是很诡异的情况 ;
如果考虑到这一点 ,