文章讨论的「用户账号系统」，主要是从「建立用户」角度进行讨论，涉及用户的登录、注册、第三方应用等。
一、阐述用户账号体系的功能性和拓展性
用户是产品的基础和目的，一切创意，一切功能，皆为其服务。因此，用户账号系统，于产品而言，是一个重要的核心。所以，类似用户账号系统这种基础性的功能系统，在设计层面上，难点和重点都是显而易见的。重点是既要保证他的·功能性，难点即是又要保证其拓展性。
（1）功能性
用户账号系统，可能乍眼看上去，说得比较大，通俗一点，就是管理用户账号系统。那如何管理？就是对用户账号的增加、删除、查看、修改。如果再换一个表达方式，那就是“注册、登录、修改信息”。这就是用户账号系统的功能性的设计重点。
虽然这些功能，看上去比较简单，实现方式也不难。可是这是面对用户第一道门槛，因此在界面设计和用户体验会抓得比较紧。
（2）拓展性
那么，如何理解用户账号系统的拓展性，这里基于业务列出几个例子：
1.第三方授权登录
登录的方式，从早期的「账号+密码」，这种方式实现非常简单，可是有一个最大的痛点——容易被遗忘。
后来，逐渐演变成「邮箱+密码」，「手机+密码」，由于邮箱、手机等信息，都是大家经常使用的内容，所以，可以降低遗忘率。可是正常的用户账号需经历两个过程：先注册再登录，略繁琐了。
为了可快速登录，跳过注册流程，也产生「手机+验证码」这样的登录方式。
同时社交产品发达，微信、微博、QQ等社交产品都有相关的SDK，可协助一键登录。这样「第三方授权」登录方式也诞生了。
第三登录是登录方式演变和拓展，用户账号系统要满足此拓展。
2.同平台多账号绑定和解绑
第三方授权登录，虽然可以实现快速登录的目的，可是，第三方仅仅对外开放OpenID，用户的详细信息还是存留在第三方中，产品只能得知第三方公开的信息。但是产品都是需要自建用户体系，因此现在平台的账号体系和第三方授权的方式都是并存的。
正因为两者是并存的，所以，同平台就会出现多账号情况，用户通过手机/邮箱创建一个账号，然后又通过第三方授权创建了其他账号，绑定需将其全部捆绑在一次，可协助用户管理多个账号。而解绑，则是其的逆反应。
3.不同平台的账号打通
现在每家公司都不会只有一款产品，而是会以某个成功产品为核心，延伸更多其他类型的产品。因此，每个产品都会有其对应的用户体系，但是用户账号系统，基本都是唯一的，它需要满足不同的产品。
所以，接下来，需要总结如何处理以上重点和难点。
二、第一重点——登录
（1）登录方式的介绍
（2）相关的前端界面设计
1.账号/邮箱/手机 +密码登录为主
这是最常见的登录方式，适用于普遍的产品。
例1：豆瓣
2.手机+验证码登录为主
「手机+验证码」的登录，又名「免密码登录」或者「快捷登录」。
起源于团购类的产品，用户在购买商品，浏览、筛选、放入购物车，填写订单信息，最后一步付款，此时发现自己没有登录，因此，在这里提供快捷登录方式，免去其注册登录繁琐的流程，快速让用户完成订单。
在实际运用上，大家都发现，这种方式优势明显，既可以保留用户信息，又可以快速注册登录，提高用户体验。因此现已经是成为登录方式一个很重要支线了。
例子1：轻芒
Tips：
1.输入手机号->输入验证码，中间是有一个过程的
（A）检测手机是否正确，包括是否11位，是否满足不同地区的电话格式等
（B）然后告知服务端发送验证码
这个过程，以往都是同一个页面实现——即“填写手机号+验证码”，同一个页面对熟悉的用户有较大的优势。可是同一个页面出现两个按钮：“发送验证码”和“登录”，会容易让用户混淆，不太清楚流程先后。
所以，现在很多产品都改善，使用分步（如例子所示），一页面承载一个功能，一个复杂的任务拆分成几个小任务，逐步引导用户完成，既给复杂的任务处理腾空时间，也让用户快速了解产品流程。
3.验证码登录和密码登录并行
上文讨论过，验证码登录有其快捷方便又保留用户的优势，而密码登录历史悠久，实现简单。所以也有一部分的产品都同时保留这两种登录方式，兼容新老用户。
4.第三方授权登录为主
第三方授权登录，于用户而言，是方便至极，无需填写任何信息，只需要授权登录即可。可是于产品而言，第三方登录只公开OpenID，因此很多用户数据，仍然在第三方，不利于后续工作展开，因此，很多产品都会登录后引导用户绑定手机或者其他信息。
然而，在产品的初期，也可不妨全面植入第三方授权，因为用户系统需时搭建，初期的产品步伐较轻，可将核心放进产品核心功能，使用第三方授权登录方式，一来于用户而言，注册登录成本几乎没有，低门槛让用户快速体验产品；二来可以验证产品的市场接受度。
三、 第二重点——注册
注册有三板斧：用户名（手机/邮箱），验证码，密码。
但也有部分产品会增加「填写用户资料」的流程（如头像、性别、生日等等），以期待可以和用户建立关系。
若增加「填写用户资料」的流程，也要思考：
A.步骤是阻断性的还是可跳过？
B.内容哪些是必填，哪些是希望填？
站在用户体验角度，每增加一步功能或者内容，用户需要去思考，也容易出现流失。
除此之外，在用户登录注册的模块里，着重分析一下注册的交互——分步注册。
（1）分步注册（Wizard 向导模式）
注册是一个很成熟的流程，所以在交互层面上很建议使用到分步注册，这和“Wizard（向导模式）”有异曲同工之妙。
Wizard模式在PC时代是十分流行，微软在安装软件时，大多数软件都是一步一步引导用户如何安装，将安装任务拆分成几个小任务，一个页面承载一个小任务，用户每次只需完成一个，直至全部完成。（上文也有涉及）
这样做有什么好处：
通过分解复杂工作流帮助用户更快的掌握内容
通知用户当前任务进度使其了解整个工作流的概况
将复杂流程分步进行能够提供充分的任务处理时间，避免用户长时间等待
国外某公司做过A/Btest，发现分布注册的转化率高于非分布注册
所以，注册流程，我们也引入这样的思维。拆分注册流程，每一个页面只承担一个作用。
四、第一难点——多平台账号打通
随着互联网的深入发展，对于公司来说，旗下不仅仅只有一款产品，可能是多个产品并行。因此于某个公司而言，用户账号体系只有一套，而且非常基础，可以面向不同的产品。
举个例子，网易系的产品，如考拉海购、网易云音乐等，账户体系是依赖于网易的邮箱。包括我工作上负责的产品：约约、MOJIKIDS、HOBBYLAB等的账户体系是由手机账号承载的。
这种需求是存在的，那我们怎么解决多平台账号打通呢？
接下来，会从技术的角度去谈论这个问题，可能说得不一定完全正确，毕竟我是负责产品工作。可这个问题需从服务端入手，从技术角度剖析，虽然不是我的强项，可是我对这个解决方法是很好奇，为此，我询问了程序猿和上网查阅了相关资料。
（1）认识三个参数
（1）AppID：接入用户系统时，首先分配，用于区别接入的各个APP
（2）UnionID：用户手机注册时，由用户系统根据手机号创建，在用户系统作为用户唯一身份标识
（3）AppUserID：用户注册时，由App服务端根据Union或者第三方授权的OpenID创建，在App内作为用户唯一的身份标识
（2）基本流程
解释：
（1）用户注册
使用手机注册，首先判断手机的正确性和验证手机，若符合要求，检查手机是否已经存在，若存在，就去引导登录；若不存在，服务端就会创建手机UnionID，同时也会反馈给App端，创建AppUserID并关联UnionID
（2）用户登录
使用手机密码登录或验证码登录，如注册时检查手机，若手机账号是新增的，流程和注册一致；
若手机账号已存在，服务端查询对应的UnionID，再返回APP端，查看UnionID是否在该APP存在过，若是，就查询到AppUserID并成功登录；若否，就创建AppUserID，并且登录。
这是一个普遍的做法，第一，保证UnionID的唯一性，确立用户账号体系；第二，可以让不同App独立，虽然大家有相同的UnionID，可是不同APP有相关的用户信息。
（3）基本原则
根据以上的流程图，我们可以获得以下的基本原则：
- 当手机号作为唯一注册途径，用户每次手机注册时，都会在服务端新建一个UnionID，然后返回对应的APP（使用AppID跟踪）创建相关的AppUserID
- 一个UnionID可对应N个AppUserID
- 第三方授权OpenID，只会存在APP里，即创建AppUserID，并没有创建UnionID
工作心得：
这样流程，是现在总结比较恰当的账户体系，可兼容多平台。但在自己的负责项目，并不是这样流程，区别的地方是，第三方授权的OpenID也可以创建UnionID，这里好处可以快速增加用户体系的用户数量，可是解决同平台多账号问题时，因为这样机制导致绑定和解绑环节很多坑，会非常折腾。
若没有存在历史原因，建议一开始用户体系需思考长远一点，如兼容多平台。
（4）问题解答
1.多平台的时候，用户资料等用户信息是如何管理？
答：首先归纳一下现在主流的用户系统服务端设计：
app级的用户系统，根据手机号邮箱注册或第三方授权创建用户身份，用户的身份信息、账号绑定、个人资料都保存在app服务端也只对单一app有效；普遍中小app都是采用的此种。公司级用户系统，根据手机号邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，对接入的app有效，app端有读取修改权限；平台级用户系统，根据手机号邮箱注册创建用户身份，用户的身份信息、账号绑定、个人资料都保存在统一的公司用户系统服务端，选择极少信息提供公开接口，接入的app只有读取权限；例如qq微博微信等第三方授权。
我工作的情况，是第二种为主，公司级用户系统。这里举两个例子：网易（网易云音乐，考拉海购、网易严选）和百度（百度贴吧、百度地图）。
（1）网易公司的用户系统是网易邮箱去承载，但是承担功能仅有一个用户身份即UnionID，用户资料、账号、第三方登录等都是由APP自己去实现和修改。
（2）百度公司的用户系统是百度账号去承载，不仅有UnionID，还包括用户资料、第三方登录、账号等等都是保存在用户体系中，App端都有修改权限用户系统资料。
那我们看得出，用户资料管理方式有两种，一种是储存在App端，一种是储存在用户体系。网易是储存在App端的，而百度储存在用户体系。究其原因是：
- （1）百度偏向工具，所以对于用户资料并不是很高要求，只需有昵称、头像等基础元素即可，资料保存在用户体系，app端直接接入即可
- （2）网易偏向个性化，不同产品有不同的用户体系需求，所以将资料存放在App端，可以满足多样性，又互不打扰
我负责的产品，则是参考了百度的做法，将用户资料存在用户体系中，这样在我们不同的产品App上可直接修改相关昵称、头像等。
为啥会有这种初衷？因为我们的电商产品，用户关心的是买买买，而对个性化要求并不高。我们不希望让用户花时间放在用户账号上。
2.为什么不用手机作为唯一识别方式？
答：不使用。站在用户的安全性，手机是一个可变量，用户可能丢失手机无法找回，更换手机，甚至激活旧手机号码造成账号资料泄露。
手机号是我们保证账号安全性的一手段，常用方法有以下：
- 绑定/解绑手机
- 设置安全问题
- app用户行为验证
- 账号申诉
五、第二难点：第三方授权登录
难点1提出的基本原则，也写道，第三方授权的用户不是用户系统的用户，仅是单一App的用户。因此就这个原则，第三方授权登录流程如下：
解释：
(1)第三方授权注册登录
调取第三方sdk，查询此openid是否已有appuserid；若是，登陆；若否，创建appuserid并将基本资料存入app服务端；
我负责的产品——约约，还有尚早版本的京东，并非按照上图流程。
区别地方是，第三方授权的OpenID是直接进入服务端查找是否有UnionID，再由UnionID创建APPUserID这里会有问题的，第三方授权OpenID和手机号在用户体系中是同一个层级，可创建UnionID。若手机号和第三方授权绑定在一起，就会出现两个UnionID，发生冲突。所以不建议这样的方式实现用户账号体系。
六、第三难点：同平台多账号的绑定和解绑
（1）账号绑定
账号绑定主要分为：绑定手机号和绑定第三方授权账号。
账号绑定是为了避免用户忘记其登录方式，有利于用户操作，也有利于产品用户的信息留存。
1.绑定手机号
- Step 1：用户输入手机号并获得验证码，客户端进行基本手机判断，App服务端发送验证码给用户
- Step 2：用户系统服务端验证手机是否已经存在对应的UnionID
- 若是，提示已绑定此手机号，需更换手机号
- 若否，按照手机号注册流程，用户系统创建UnionID，将UnionID传给App并关联当前登录的AppUserID
2.绑定第三方授权
- 授权后，查询App服务端是否存在AppUserID
- 若是，提示此号已绑定，建议先解绑
- 若否，将OpenID绑定到登录的AppUserID中，绑定成功
所负责的产品，并不是这样实现绑定，上文提到，由于历史原因，手机号和OpenID是同一个层级，都有可能生成UnionID，那出现这种情况，如何解决？
提出以下的解决方案。
实际工作中，由于第三方授权登录，对于产品的用户资料的收集影响略大，所以通常第三方授权登录之后，就需要立即绑定手机，不允许用户跳过。
（2）账号解绑
（以下内容摘自《用户系统(下)第三方授权、账号绑定及解绑》）
账号解绑也只是针对手机号和第三方授权。
1.手机号：只允许更换手机，不能解除绑定
- Step1：原手机号+验证码，app服务端验证是否为真，为真发送验证码；
- Step2：新手机号+验证码+密码，app服务端验证手机号+验证码是否为真，为真进行step3
- Step3：用户系统服务验证此手机号是否已存在unionid；
- 若是，提示更绑失败
- 若否，将新手机号替换原手机号，关联原手机号unionid，appuserid；并将原手机号从用户系统中删除；
我的工作心得：在现实工作中，过程并没有如此繁琐，实践中是直接去掉Step2，首先验证旧手机，然后再验证新手机，两者通过即可更换手机。
2.解绑第三方授权
- Step1：当前第三方授权是否已经绑定手机号，若是，成功解绑；若否进行step2
- Step2：当前第三方授权是否绑定其他第三方授权登陆，若是进行step3，若否提示无法解绑，首先请绑定手机号；
- Step3：当前第三方授权是否为最早一个绑定（即注册账号）；
- 若是，调取第三方授权登陆页面，用户重新登陆要解绑账号+密码（需要确认是否能抹除用户登录信息要求输入账号密码），登陆成功则解绑成功；
- ps：这里被开发同事验证不能抹去登录信息，因为我们只有调取接口的权限。但是当时之所以想要这么设计，是为了账号安全，可以试想一个场景，我把你的账号绑定到我的微信／微博等，然后接触你的账号，相当于这个账号就归我了。－－事实证明现在的权限没办法解决这个问题。
- 若否，解绑成功。
我的工作心得：第三方授权解绑Step1就要检测是否绑定手机，因为没有绑定手机，会导致后续解绑流程略偏复杂，用户会有疑惑。
所以，更推崇当初第三方授权登录，就必须引导用户绑定手机。这样才可以维护用户账号信息和简化后续的登录，也简化后续出现意外时，让用户快速处理问题，如解绑问题
