用户体系之账户设计

---

前言

随着互联网的发展，越来越多的应用、网站需要用户进行登录才能使用。为了方便用户登录，现在的应用通常提供多种登录方式，比如手机号、微信、抖音、快手 … ，这样你就不用干巴巴的记下账号、密码，通过几种常见的登录方式快速登录，如：

这篇文章将介绍如何设计一个用户体系，包括认证登录、账号绑定、账号管理等多个功能。在设计功能时，需要考虑到用户体验、系统安全等因素。

另外如何保证同一个用户在不同的登录方式下账号唯一，在本文中我们将重点放在账号设计上。

---

一、需求分析

1、登录功能

登录功能是用户体系的核心功能之一，它需要实现用户身份认证，保证只有合法用户才能使用应用程序。常见的登录方式包括手机号、微信、抖音、微博等。

对于手机号登录，通常需要用户输入手机号和验证码。在输入手机号后，系统会向用户发送验证码，用户需要输入验证码进行验证。验证码可以有效防止恶意注册和登录，提高账号安全性。

对于微信、抖音、微博等登录方式，通常需要用户授权，即用户需要在对应的应用中授权使用微信、抖音、微博等账号进行登录。在授权后，系统可以获取用户的基本信息，比如昵称、头像等。

为了保证用户账号的唯一性，在用户第一次使用某一种登录方式登录时，系统需要为该用户创建一个唯一的账号，并将该账号与该登录方式进行绑定。

在用户使用其他登录方式登录时，系统需要验证该用户是否已经存在，如果存在则直接将该登录方式与该账号进行绑定，否则需要为该用户创建一个新的账号，然后将该登录方式与该账号进行绑定。

2、退出功能

退出功能是用户体系的另一个重要功能，它需要实现用户退出应用程序，保证用户的账号安全。

在退出时，系统需要清除用户的登录状态，并且保证用户下次登录时需要重新输入账号和密码或者重新授权。

3、账号绑定功能

账号绑定功能是用户体系的一个扩展功能，它可以让用户将多个登录方式与同一个账号进行绑定。比如，用户可以将手机号、微信、抖音、微博等多个账号与同一个系统账号进行绑定，这样用户可以使用任意一种账号登录系统，而无需再进行其他操作。

为了实现账号绑定功能，系统需要为用户提供一个用户账号管理页面，让用户可以在该页面中对账号进行管理。在该页面中，用户可以添加新的登录方式，删除不需要的登录方式，或者修改已有的登录方式。同时，系统需要保证在任意一种登录方式下登录后，用户都可以访问到该账号管理页面，以便于进行账号绑定的操作。

另外，管理端也要设置用户基本信息管理页面，也同样可以对用户账户进行管理，比如绑定、解绑等，当然，这需要设置一定的操作权限。

3、其他注意事项

除了上述介绍的功能外，还有一些其他的注意事项需要考虑，以保证用户体系的完整性和可靠性。

1）手机号加密

为了保证用户账号安全，尤其是手机号信息泄漏问题，系统需要对用户的手机号进行加密存储。常见的加密算法包括MD5、SHA1、SHA256等，系统需要选择合适的加密算法进行密码加密。

2）安全性验证

为了防止恶意登录，系统需要对用户进行安全性验证。比如，可以在用户登录时进行IP地址验证、设备信息验证等，以保证用户的账号安全。

3）防止重复提交

为了保证用户体验，系统需要防止用户进行重复提交。比如，在用户登录时，系统需要对用户进行验证，如果用户已经登录，则直接跳转到应用程序的主页面，而无需再次进行身份认证。

4）账号注销

为了保证用户的隐私权，系统需要提供账号注销功能，让用户可以自主选择注销账号。在用户注销账号时，系统需要清除用户的所有相关信息，并且保证用户无法再次登录。

二、账户设计

1、表设计

账户表：

字段名	类型	描述
id	int	用户唯一标识
nickname	varchar	用户昵称
avatar	varchar	用户头像地址
gender	int	用户性别，例如 0 表示未知，1 表示男性，2 表示女性
city	varchar	用户所在城市地址
email	varchar	用户邮箱地址
phone_number	varchar	用户手机号码
created_at	datetime	账户创建时间
updated_at	datetime	账户更新时间

手机号账户表：

字段名	类型	描述
id	int	用户唯一标识
phone_number	varchar	用户手机号
user_id	int	关联的用户唯一标识
status	int	用户状态，0：正常，1：禁用
created_at	datetime	账户创建时间
updated_at	datetime	账户更新时间

第三方账户表：

字段名	类型	描述
id	int	第三方账户唯一标识
type	int	第三方账户类型，例如 1 表示微信，2 表示QQ
openid	varchar	第三方账户唯一标识
nickname	varchar	第三方账户昵称
avatar	varchar	第三方账户头像地址
user_id	int	关联的用户唯一标识
created_at	datetime	账户创建时间
updated_at	datetime	账户更新时间

2、QA

问：为什么需要第三方授权登录？

信息时代，各种网站、app 多如牛毛，每个都去设置一个账号密码，你记得住？

现在很多人都会有强依赖的手机应用，比如微信，如果我们可以通过微信授权登录，是不是很方便？

问：第三方授权登录的原理？

现在很多大的平台，比如微信、微博等都会提供【开放平台】给企业开发者进行联调对接，简单的开发对接即可获取到平台的用户信息（当然，非常有限），不过，一般够用了。

对接过程：

• 一般企业需要先在平台注册开发者账号，拿到开发者账号对应的 appId、appSecret 作为接口交互时的校验凭证。
• 用户点击登录页，企业应用向平台发起二维码请求，企业应用获取后返回给用户扫码
• 用户扫码后，平台返回扫码授权 code 给企业应用（通过回调url传回企业应用，注册开发者账号时会填写回调url）。
• 企业应用通过 code、appId、appSecret 获取预先访问平台凭证 access_token，当然也会携带 openid、unionId等返回
• 企业应用通过 access_token 获取平台提供的用户基本信息。

目前平台（如微信）一般采用 Auth2.0的授权方式，以上便是 Auth2.0 请求授权的基本流程。

问：表结构设计的考量？

• 基础账户表：毫无疑问，系统最重要的账户表，相当于用户身份凭证
• 手机号账户表：目前最常见的登录方式之一，手机验证码登录，无需三方系统授权
• 三方授权账户表：微信、抖音 这类普及率极高的应用，也可以作为登录凭证；当然，需要事先与基础账户表的用户进行绑定

在这种设计下，用户可以通过基础账户或第三方账户进行登录。当用户使用第三方账户登录时，系统会根据该第三方账户在第三方账户表中查找对应的记录，如果存在，则说明已经存在基础账户，如果不存在，则会创建一个新的基础账户并关联到该第三方账户。

这种设计可以将基础账户信息、手机号以及第三方账户信息进行分离，使得基础账户表只存储系统唯一账户信息，同时也可以很好地支持「多种登录」方式。

问：三方账户放在一张表里会不会不太好？比如扩展性不强？

如果需要更加灵活地支持多种第三方账户类型，也可以考虑使用关系型数据库的多态特性来实现。

例如通过一个公共的第三方账户表来存储所有第三方账户的公共属性，然后针对不同的第三方账户类型再创建对应的子表来存储特定属性。这种设计可以进一步提高系统的扩展性和灵活性。

问：三方账户按三方独立分表存储如何？

微信账户、抖音账户以及微博账户 … 各类三方账户数据完全隔离：

• 其优点是每个表只存储对应的第三方账户信息，可以更加方便地查询和维护。同时，这种方案也具有更好的扩展性，可以很方便地支持多种第三方账户类型。

• 不过，这种方案也存在一些缺点。首先，由于每种第三方账户类型都对应一个单独的表，因此需要更多的表空间和存储成本。其次，由于不同的第三方账户类型信息存储在不同的表中，如果需要查询所有的第三方账户信息，需要进行多次查询和数据合并操作，会增加查询的复杂度和开销。

与此相比，将所有的第三方账户信息存储在同一张表中，可以更加方便地进行查询和数据分析，同时也可以减少表的数量和存储成本。当然，这种方案也需要考虑到表结构的设计和索引的优化，以便提高查询效率和系统的扩展性。

总的来说，对于不同的业务场景和需求，需要根据实际情况选择合适的方案。如果需要支持多种第三方账户类型，并且需要对第三方账户信息进行查询和分析，可以考虑将所有的第三方账户信息存储在同一张表中。

如果需要更加灵活地支持多种第三方账户类型，并且需要进行更加复杂的查询和分析操作，可以考虑将不同的第三方账户类型分别存储在对应的表中。

问：哪种更好？

实际上，不同的业务场景和需求会选择不同的方案。在很多情况下，系统会默认支持多种第三方账户类型，例如微信、QQ、微博等，这时候将所有的第三方账户信息存储在同一张表中会更加方便查询和维护。

但是在一些特殊场景下，例如某些系统只支持一个或少数几种第三方账户类型，或者需要对不同类型的第三方账户信息进行更加复杂的查询和分析操作，此时将不同的第三方账户类型分别存储在对应的表中会更加灵活和高效。

因此，需要根据具体的业务需求和系统设计来选择合适的方案。在设计系统时，需要综合考虑系统的扩展性、查询效率、存储成本等因素，并根据实际情况进行权衡和取舍。

三、实践

1、账户密码登录

对比系统账户表的账户id与账户密码是否一致，一致则登录成功。

需要注意的是：

• 表单提交时，密码要加密
• 数据库存储密码时不能存储明文

2、手机号登录

利用验证码登录即可。

短信验证码这块可以作为底层基础服务，于业务之外独立实现部署，仅对业务层提供短信发送、验证码验证接口抽象。

验证成功之后需要对账户进行维护：

• 没有手机号：手机账号表新增记录、并创建系统账户，然后与手机号账户关联
• 有手机号：查询关联的系统账号

后面就是生成登录凭证（token）~

3、第三方授权登录

这里以微信登录为例：先找到开放平台提供的对应文档：微信登录功能

我们看看整体流程图：

主流程：

• 用户点击登录页，企业应用向平台发起二维码请求，企业应用获取后返回给用户扫码
• 用户扫码后，平台返回扫码授权 code 给企业应用（通过回调url传回企业应用，注册开发者账号时会填写回调url）。
• 企业应用通过 code、appId、appSecret 获取预先访问平台凭证 access_token，当然也会携带 openid、unionId等返回
• 企业应用通过 access_token 获取平台提供的用户基本信息。

拿到这些信息后，我们就可以存入第三方账户表，其中 openid 或者 unoinid 一般作为三方账户的唯一凭证，与系统账户表相互关联。

后面的登录凭证（token）就是企业自身去实现了，三方授权登录就算结束。

4、账户统一

账户登录解决了，接下来还需要解决账户统一的问题，比如一个用户有微信、抖音、手机号等多种登录方式，要把他识别成一个系统用户。

这个时候你需要给 C 端用户提供绑定、解绑功能，方便用户关联对应账户。

另外，B 端也可以提供有管理用户权限的 绑定、解绑功能，方便管理用户。