互联网的账号自带备忘机制；
一、业务背景
通常在系统研发的过程中，需要不断适配各种业务场景，扩展服务的领域和能力，一般会将构建的产品矩阵划分出多条业务线，以便更好地管理；
由于各个业务线的数据入口和管理策略的不同，这样从不同路径下沉淀的数据，可能因为系统边界问题从而被孤立；如果用户数据被分裂，会因为数据不全面给分析决策带来误导；
比较经典的场景，用户从应用端完成注册之后，通常不会过多提供自身信息，由于业务需要不断丰富用户画像，所以用户数据通常会被调度到独立的管理系统中，通过不同的触点反馈进行信息扩展，比如采集埋点数据，线下接触，营销电话等；
这种情况从操作上是有明显感知的场景，显然用户在应用库中的数据和在管理库是存在很大差异的，在真实的情况中用户可能在不同的应用和场景中会产生重复，必然会导致用户数据难以统一维护；
二、唯一标识
用户的行为数据在当下的互联网产品中，是极其具有分析价值的，不同的应用端不管是否处于登录状态，在产品中产生的数据都是有记录的手段，进而在数据层面分析识别；
这些编号最大的特点就是具有唯一性，可以标识用户在不同终端不同状态的操作信息，而当这些数据沉淀到系统时，会根据端口和操作类型进行存储，不同的终端下其数据唯一标识也不相同；
从数据分析的角度上来看，显然不希望用户的行为信息被分裂并且各自孤立，这样对多终端多状态下的用户行为数据进行全域关联，是行之有效的方式，其基本原理涉及到ID的映射技术；
三、Id映射
基于上述的业务情况，在产品矩阵中提供用户身份的全局统一标识至关重要，用户实体在不同业务线所产生的行为数据，通过唯一序列号进行识别，这样进行用户分析时看到的画像比较全面；
在当下的互联网产品中，基于手机号创建应用账号的模式已经是常见功能，手机号注册之后，再通过手机号去关联相应的终端ID，从而使各种孤立的数据被链接起来；
其实现的原理并不复杂，首先需要提供一套映射库，当新的手机号被系统识别采集时，在映射库中新建一条数据，手机号和对应的唯一ID，此后其他路径的数据，如果手机号相同则绑定在该ID下面；
四、数据关联
在ID映射机制下，虽然各个业务线数据相对孤立，数据之间不会产生直接影响，但是实际上已经被唯一ID串联起来，这样将ID关联的数据进行综合分析，准确性会提高很多；
不管从任何路径或渠道下采集的数据，如果存在手机号的维度，或者手机号相关联的序列号标识，判断该手机号是否存在全局映射ID，没有则在映射库中创建对应关系，如果有则直接绑定即可；
在执行数据的全局调度和分析时，则通过映射库的标准关系，基于ID标识将全部业务线的数据进行查询和统筹分析，从而生成相对全面的数据档案，以及标准的分析逻辑；下面给出一个参考性的结构设计：
这里存在数据关联的逻辑，ID标识与手机号都是唯一的且一对一，但是手机号与终端的序列号可能存在一对多，甚至是多对多；账号与应用中产生的行为数据，虽然追求准确性，但是精确度不会过度要求；
这种情况下就需要执行相应的业务策略，比如同一个手机号可能登录过不同手机中的相同应用，手机中的应用也可能被多个账号登录过，此时则需要基于策略做关联上的取舍，可能是账号登录时长，或者登录前后的时段，无法一概而论；
五、注册登录
以手机号作为账号主体为例，开放的应用并不会明显区别注册和登录，以此简化操作避免阻断掉用户，在通过手机号登录时，如果是未注册的用户直接进行信息初始化即可；
- 用户在登录表单中，输入手机号并获取验证码；
- 在登录服务中，生成并维护验证码的时效；
- 验证码需要借助对接的第三方短信平台推送到用户手机中；
- 登录表单填充验证码之后提交登录信息进行验证；
- 当登录验证成功之后，如果用户未注册则初始化账号体系；
- 账号体系校验和维护之后，通过异步方式关联ID标识；
- 最后需要给用户端返回Token身份令牌，作为账号识别；
注册登录集成在一起的复用接口比较复杂，但是以最短的路径让用户快速使用产品，通过行为数据采集分析，从而可以精准识别用户需求，进行正确的引导和营销，发挥出数据的真正价值；
这里给出一份账号管理的结构设计参考，通常情况下用户的主表维度会围绕可登录的账号来设计，而涉及到信息采集的数据会写入用户档案表，由于不同业务场景对信息依赖不同，所以在用户注册之后会引导各种数据采集的页面；
用户身份识别和账号作为系统非常基础的核心能力，在设计的时候既要有用户体验，同时要重视数据的安全性；作为核心能力在前期设计的时候就需要一定的前瞻性，做好可能性的规划和结构预留，避免后续的迭代跨度过大。
六、参考源码
代码语言：javascript复制编程文档：
https://gitee.com/cicadasmile/butte-java-note
应用仓库：
https://gitee.com/cicadasmile/butte-flyer-parent
