用户账号（指的C端账号，分享也是基于此）其实是一个不那么新奇的功能，一直在随着互联网的变迁而变化；用户账号是一个比较底层比较核心的模块，在企业不断扩张以及业务不断增加的情况下，怎么做好一个 “体验好”，“安全性强”，“易对接” 的账号中台其实是不容易的，接下来就给大家分享一些实战中的一些总结！
经过一些实战中的积累，总结了一个账号产品的架构分享给大家，接下来分按照不同的模块进行详细的说明：（文章中任何的图片不得在本人没有授权的情况下，随意转载）
目前大多数的登录逻辑里面是包含了注册的，也就是说用户登录如果没有注册就默认帮助用户注册并登录成功，这样体验会更好，如下流程：
优缺点：目前大部分的平台已经不使用这种方式了，因为这种安全性不高且与用户的关联性不大。
适用场景：有些场景用户没有手机号或第三方的账号就只能用这种形式了，例如：如果你的产品用户是小学生，没有手机也没有手机号只能使用这种注册方式了。
注册方式：用户自己输入手机号，平台将发送验证码给到用户，用户填写正确的验证码后即注册成功。
缺点：短信容易收不到（可以通过手机号+语音验证码解决），填写短信验证码的时候有一些麻烦（Android系统可以通过获取短信内容自动填充来优化体验）。
注册方式：用户输入自己的手机号，平台将给到用户打语音电话并告诉用户验证码，用户填写正确的验证码后即注册成功。
适用场景：在收不到短信验证码的场景下可以使用（一定要控制在用户第一次点击短信验证码，且没有输入验证码的情况下，再展示语音验证码，来控制成本）。
注册方式：用户授权平台可以获取用户的 userID，头像，昵称等信息即注册成功。
缺点：没有触达的方式不方便后期的运营，容易出现同一个用户存在多个账号，因为有可能用户选择用不同的第三方账号分别去登陆。
适用场景：纯工具类，或者社区类的产品可以使用这种注册方式，以及产品业务比较早期的阶段，为了让用户尽快体验到产品的核心价值。
优点：用户接受度广，有了用户的手机号不存在多账号，后期的运营可以触达到用户。
适用场景：适用大多数的业务场景，有一些产品早期会将绑定手机号的操作放在用户进行某项核心操作前例如下单前，发布作品前等。
缺点：有少数场景用户选择非本机号，所以要结合用户手动输入手机号一起使用。
修改方式：当用户验证码注册时填写的手机号或者用户账号绑定的手机号，即可修改为新的密码
修改方式：当用户验证码注册时填写的邮箱或者用户账号绑定的邮箱，即可修改为新的密码
个人中心本质：就是用户身份信息的管理，以及一个小型的用户画像，既可以为业务提供通用的用户数据，也可以为用户画像的基础数据。
个人中心数据来源：一部分让用户自行填写，例如用户注册完成后让用户选择或者填写一些数据；另一部部分是对用户登录数据或者操作数据的一些收集。
第一步，对于注销这个功能是不得不提供的一个功能，目前很多应用市场上架前对应用进行审核时如果发现这个应用没有注销的功能，可能会不让上架。
第二步，用户提交注销前一定要对用户的身份进行校验，第一个防止非本人操作苹果7怎么注册国外id，第二个系统层面会更加安全。
第三步，用户提交注销后一定要预留一个用户反悔的时间，一般是半个月或者一个月，因为注销用户对企业本身来说是一种损失，我们也需要尽力服务好用户减少这种流失。
（1）提供对外接入方式时95%以上提供统一页面（页面需要做的灵活已配置），因为方便管理并且可以大大的增加效率；如果提供过多的API出去后期想优化一些有关页面的需求时，一方面：推动沟通的成本非非常高，另一方面：不是所有的团队都有那么多资源可以及时配合你去做技术修改的；例如：公司周年庆需要改登录页的风格以及画面，如果提供的统一的页面，只需要你自己修改通知到其他团队就行，如果你提供的是API那就麻烦了所有的应用全部都要跟着改动。
（2）剩下的5%提供API，总有一些业务的场景你是很难覆盖全的，这部分可以通过API来提供；总之一能用统一页面的就不要使用API 。
账号管理后台，是为了方便做账号配置，数据监控，异常处理等综合的管理平台：
（1）应用管理模块： 对接入应用进行管理，记录应用的基础信息，并提供需给应用做单独配置的功能，例如：接入统一账号的应用名称，应用的唯一标识ID，应用的说明，应用所属部门，应用对应的负责人等等，这些信息是发现有谁在使用账号以及后续账号出现需要功能迭代沟通时的基础数据非常重要，包括需要单独给应用做特殊的配置也需要放在这里。
（2）用户管理模块：对注册用户进行管理，记录脱敏后一些基础信息，并提供一些给用户标记或辅助操作的功能；例如：有时候公司的运营自己注册了用户，但是很多操作的数据都是为了做测试的数据，这部分如果数据量过大的话 一定需要跟真实用户作区分，标记为内部用户；还有一些恶意用户需要标记为黑名单用户杜绝这类用户再次登录。
（3）账号配置模块：用于账号整体配置的模块。例如：提供统一页面的配置，配置页面颜色的风格，页面控件，页面的logo等；还包括短信验证码，语音验证码，图形验证码的配置等。
（4）账号日志模块：记录所有对账号服务进行增，删，改，查相关操作日志的模块，不管是 用户，后台运营人员，还是接口调用方；目的为了监控，追踪，溯源。
（5）数据分析模块：统计账号提供的功能使用数据情况。例如：用户填写数据导整个注册完成的成功率以及所花费的时间。
（6）接口管理模块：提供接口开关，接口调用量统计，核心接口失败警告灯服务。
（7）协议管理模块：提供协议的上传以及协议签约记录的模块。重点说明：目前工信部对互联网个人的隐私管理的非常严格，所以用户服务的条款与隐私协议是账号必须模块。如果对这块不是很了解的可以看我之前的文章。
账号中台是一个核心偏底层的服务，作为产品经理一定要清楚的，你的模块中有哪些比较核心的数据，以及这些数据都是用做什么国外苹果id怎么下载中国app，这样你在设计的产品或处理复杂异常场景的时候你会得心应手。
用户信息：（姓名，年龄，邮箱，手机号，性别，职业，学历，昵称，证件号），
其实底层数据都是给以后能的规划打基础，特别是作为几十个或上百个业务使用的账号中台，底层数据非常的重要。
有这四层的数据，账号平台可以清楚的知道 用户是从哪个应用端注册进来的；有这四层的数据，账号后续想根据不同的业务，产品，应用做个性化的配置，才有标记为。（层级的划分，根据公司的组织架构来，如果创业型公司建议，前期对增加一些层级备用，防止公司做大后，需要额外的增加）
这些底层数据很重要，一定要把账号整体的规划想全，然后第一个版本就要吧底层的数据做好；这样后面做起来就轻松很多，如果前期不把基础打牢固，后面再想去收集这些数据会异常艰难。
所以其实真正做产品的高手，不是遇到需求时才解决；而是先把可能预见到的需求早就想了一遍，然后在第一个版本就把基础打好。
使用场景：主要是通过手机号接受验证码的场景，在手机号接受短信前，先通过图形验证码防止被恶意的刷数据。
注意事项：不要每次都弹验证码，一定要给一定的数量限制，例如同一个手机号一天在平台获取短信验证码的次数超过5次就需要进行图形验证码的校验。
注意事项：控制用户使用语音验证码的场景，例如同一个页面用户联系点击了两次获取短信验证码，但是没有填写或者填写不正确的场景，展示语音验证码的入口。
使用场景：对用户输入的文本进行安全性，合规性，鉴黄等的鉴别；例如用户在输入用户名，用户签名等等
注意事项：一定需要搭配一个 文本黑白名单的功能一起使用，因为有很多的文本第三方公司是存在误杀或者遗漏的场景，而且他们短时间又不能快速的解决。
注意事项：搭配手动输入手机号+验证码的场景一起使用，因为有些用户不想使用本机作为注册的手机号。
使用场景：对用户上传的图片进行安全性，合规性，鉴黄等的鉴别，例如用户上传头像
引入第三方的服务商时，一定要从 服务可用性，业务场景覆盖度，产品的体验，客服的相应速度，技术支持的力度，价格，接入的复杂度，数据的安全性等多个维度综合评估。
相同能力的第三方服务商一定要一到两个兜底的服务商。例如：图形验证码当一个服务商的当天失败的次数超过一定次数，系统自动切换到下一个备用的服务商，进而保证系统的稳定性。
由公司安全产品经理，提供的一些设计中常见的安全规避方案。例如：用户的手机号，姓名，密码等在数据库需要加密保存，展示在页面时需要脱敏处理等等。（产品平时遇到安全性的问题是，自己也要多加总结）
弱密码稽查：密码在之前没有做格式的限定，导致用户设置的密码过于简单，在用户登录成功后提示用户修改密码的复杂度 或 定期通过密码库的查询，发现有密码安全性低的情况通知到用户去修改。
手机号/邮箱的绑定与解绑通知：用户进行核心资产的解绑时，需要通过短信或邮件通知到用户。
异地登录提醒：当发现用户的账号在非常用地登录时需要通知到用户或者增加验证码步骤。
非常用设备登录提醒：当发现用户的账号在非常用设备登录时需要通知到用户或者增加验证码步骤。
用户注销提醒：用户发起注销操作时，一定需要通过短信或者邮箱通知到具体用户。
运营商二次放号：解决之前的手机号停机后，被运营商再次放号给到其他人使用的场景。
例子：某官网，在用户注册时，只要用户输入手机号已经注册，在输入框失去焦点时就提示用户该手机号已注册；导致竞品拿不同的手机号去试，凡是已经有注册的用户就一个个给用户打电话推销自己的产品；导致了公司花费了巨额费用引入的用户，被竞品亲而一举的盗取，损失惨重。
解决方案：a, 登录注册一体化，不要分开；b，像这种非要提示的，建议验证身份后再提示，会损失一些用户体验。
例子：某官网，在用户注册时，将用户的ID展示出来了，而且用户ID的生成方式为自增；被竞品抓到漏洞，导致竞品很轻易的知道公司新增用户数，不停的使用ID自增的方式暴力破解通过用户ID获取用户信息的接口，造成用户数据的泄露。
解决方案：用户ID随机分配 以及 内部接口使用的ID与外面用户展示的ID分开。
例子：某官网，在用户注册时，没有做用户名 以及 密码复杂度的校验，导致用户大量的输入 123456 这种类似的密码。竞品通过暴力破解随意登录网站并对用户造成困扰。
解决方案：使用密码注册时，一定要有复杂度校验，不管是前端页面还是后端接口。
例子：某付费视频网站，在用户登录是没有限制登录设备数量，导致不法份子购买一个账号后，以低价大量的将此账号卖给其他的用户，导致了公司收入大量受损苹果注册国外的id下载东西吗?。
以上几个例子一方面说明，账号本身十分的重要，一不小心就容易出问题。我们在设计的时候一定要有安全意识跟思维，这种安全意识跟思维只有慢慢的积累或者学习才能形成。
用户账号并不是说一定要按照我提供的这种方式来设计，如果说业务单一简单就完全不必想我这样规划，我这方案比较适合中大型的互联网公司。
企业的不同阶段，其实对用户账号的需求也是不太一样的，企业的发展上我们大致可以分为：前期试错，扩大规模，精细化运营寻找第二曲线；每个阶段账号的侧重点是不同的，我们需要结合业务，进行一步步的迭代。
（1）提供账号的管理后台，增账号 对接，运营过程中的效率 与 异常监控。
用户账号是一个非常底层的模块，只要面向用户业务应用都需要用到；如何做到用户体验好，安全性高，易接入的账号是比较复杂的。
在设计账号的过程中，有非常多需要注意的点，接下来给大家做一个注意事项的汇总：
用户账号中心其实相当于一个小中台或微服务，中台最主要就是抽象共性，将逻辑标准化；账号其实也一样，当你在做规划的时候一定要想全，暂时不需要的一些功能通过配置先关掉，或预留技术方案方便下次升级的时候成本小。
用户账号在提供对外对接的方式时，一定要尽可能的提供统一页面的接入，这样对于以后的迭代以及统一的管理更加的高效。
用户账号的 安全与合规非常的重要，一定要在设计与规划的过程中多总结，一次安全事故对于公司来说就是非常大的损失，对于产品的靠谱能力是严重减分的。
近期持续的输出一些对大家有价值的一些文章，希望文章对大家以后产品的设计有一点点帮助，如果大家对于细节有想了解的，欢迎留言，我将一一作答。
接下来会分享 订单，支付，财务，推送，CRM等模块的分享，欢迎多多关注！
