什么是账号
账号，本质是系统里的唯一编码（用户ID），而账号名称、手机号等，更确切的理解应是导致账号生成的触发信息，即一个简单关系：自然人 - 第三方信息 - 账号。而换绑，便是替换 第三方信息。
为什么需要换绑？
因为自然人的第三方信息会更换，如不换绑，系统是无法知悉第三方信息的变更，导致无法再登录账号。
譬如 A 原先用 150手机号 注册 A账号，后 A 弃用 150改为使用185，此时A使用185登录是无法获取A账号信息，因为系统内 A账号对应的第三方信息 依旧为 150手机号。
换绑有什么注意？
1、旧第三方信息已无法使用（手机号码运营商注销），无法自行通过登录换绑。
针对这类情况，
a、同账号的其他方式登录（账号+密码）
b、拼凑登录信息，以手机号+验证码登录 举例，首先要认知，手机号码注销是指运营商不再支持手机号码的服务（短信、电话），但手机号码作为 系统内信息本质还是生效的，可以通过写入一条验证码记录帮助用户登录。
2、单一业务 账号体系 内需要注意 替换信息是否已存在对应账号。
因为自然人是一个脱离系统认知的存在，所以极有可能会先使用新信息登录，而系统自动会生成对应B账号。
针对这种情况，相应的设计会有 释放B（注销），AB直接互换（验证身份）
3、多业务并行的账号系统额外注意不同业务数据的处理。
多业务下极易发生：同一自然人 先用150 生成A账号 在 A 系统内产生数据，后用185 生成B账号 在B系统内产生数据，此后想统一用185 登录A、B系统。
针对这种情况，账号换绑其实已无法解决，因为第三方信息 跟账号的关系是一对一的，处理的方案只能是 以B账号 接收 A账号在A系统的数据，或生成C账号 接收A、B各自的数据。
该类问题在C端业务中常见的融合数据：消费记录、优惠券、余额；B端业务常见：服务记录、工单、薪酬。
4、风控
理论上系统的所有地方的数据变化、调用都会有风险，而控制风险最简单的方法就是控制数据调用，尤其是在低频事件上，譬如换绑就可以限定单一账户一年仅限一次。
具体的落地方案还需要针对具体业务场景进行设计。
