设计可拓展的账号系统【一】：手机、邮箱、用户名登录
最简版
如果只想给一个小小的网站、或个人应用增加一个登录凭证，那以下的设计已经足够，支持【用户名+ 密码】登录
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 主键 |
| username | varchar(20) | 用户名 |
| password | varchar(32) | 密码 |
| nickname | varchar(20) | 昵称 |
| avatar | varchar(255) | 头像 |
增强版
有一天，你心血来潮，突然想给网站再增加邮箱和手机号登录，最快的做法是这样子的：
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 主键 |
| username | varchar(20) | 用户名 |
| phone_number | varchar(11) | 手机号 |
| varchar(20) | 邮箱 | |
| password | varchar(32) | 密码 |
| nickname | varchar(20) | 昵称 |
| avatar | varchar(255) | 头像 |
就加这个表上面再增加2个字段，就可以了。
增强个性版
随着迭代，希望说能增加个性的东西，或者希望用户填写更多资料，按照上面的思路，我们可能会这样子做：
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 主键 |
| username | varchar(20) | 用户名 |
| phone_number | varchar(11) | 手机号 |
| varchar(20) | 邮箱 | |
| password | varchar(32) | 密码 |
| nickname | varchar(20) | 昵称 |
| avatar | varchar(255) | 头像 |
| fullname | varchar(30) | 姓名 |
| introduction | varchar(255) | 个人简介 |
| birthday | int(11) | 生日 |
额，看似没问题，但是后续还有其他个性化的东西增加进来，会发现这个表越来越大。 结合实际情况，会发现在登录操作完成后，一般展示的就 nickname, avatar, introduction 等信息。此时我们可以换个思路想，把验证的信息放置到一个表 local_auth ，个性信息放一个表user , 那表设计会如下
local_auth
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 主键 |
| user_id | int(11) unsigned | 用户id |
| username | varchar(20) | 用户名 |
| phone_number | varchar(11) | 手机号 |
| varchar(20) | 邮箱 | |
| password | varchar(32) | 密码 |
user
| field | type | comment |
|---|---|---|
| id | int(11) unsigned | 用户id（主键） |
| nickname | varchar(20) | 昵称 |
| avatar | varchar(255) | 头像 |
| fullname | varchar(30) | 姓名 |
| introduction | varchar(255) | 个人简介 |
| birthday | int(11) | 生日 |
| ... | ... | ... |
现在我们可以模拟一个用户的行为 【手机+密码】登录， 后端逻辑大概会是这样子， 先在通过在 local_auth 表 通过查询 手机+密码， 如果有返回结果， 则意味着用户存在， 得到user_id,这个时候可以去 user 表 查出对应的用户信息， 然后设置登录态和返回基本信息。
从【最简版】到 【增强个性版】, 细心的人会发现, username， phone_number, email 没有合为一个字段去做验证， 主要是考虑到用户希望登录的方式有多种，有些人倾向于 设置一个容易记的用户名，有些人不希望暴露自己的手机号， 有些人因为习惯原因，更多的是邮箱注册，
local_auth 表的设计是能满足不同人的不同习惯的。 换个思路想， 这种设计也能满足一个用户不同的登录方式。
总结：在没有第三方登录需求的情况下，最后一种设计其实是能大多数的账号需求的， local_auth， user 各司其职 。 后面也会更细致的描述这种设计带来的好处。 对于有接入第三方授权的，然后不清楚怎么设计的，我会在 如何设计一个可拓展的账号系统【二】再简单介绍下。
