背景
公司存在多个系统，但每个系统的用户数据都是独立的，因此用户每使用一个系统都需要重新注册一个账号，这带来了很大的不便。在参考了百度、腾讯等一账号登录多系统的功能后，决定开发uc用户中心系统，整合各个子系统的用户数据，实现账号通用功能。即在某一个子系统中注册账号后，其他系统也能用这个账号登录。
UC功能逻辑概述
当用户在某个子系统中进行注册时，会同步在UC中生成账号信息，并且UC中的帐号username字段唯一且不可改，注册手机号唯一但可改，即以username作为用户的唯一标志。 注意：username并不是注册时填的用户名，而是在UC中生成的，并且不会展示在页面上让用户看到。
不同子系统账号注册的差异化处理
- 如果某个子系统注册后需要审核才能登录，那使用UC中的帐号首次登录子系统时，也需要等待审核通过才可以登录。
- 规范子系统的注册信息，尽量使注册信息趋向统一。
- 在UC中注册时，若子系统A注册页不包含a内容，而子系统B注册页中包含了a内容，当用户在A系统中注册时，UC中会自动为a生成填充字段，当用户登录B系统时，再自行对a修改。
后端协同部分
1.第三方授权申请页中的redirect_url回调地址参数，是第三方授权之后跳转的页面的地址，根据具体开发方案，跟后端沟通这个参数填哪个地址，通常可选系统登录首页或后端某个地址
2.第三方授权成功后给出的code参数，是跳转redirect_url时携带在url中的，根据具体开发方案，code参数由后端操作或由前端使用
第三方登录逻辑概述
用户在登录页点击第三方登录时，跳转进入对应的授权页，授权成功后跳转到UC登录页，在这个页面会自动检测用户是新用户还是登录过的老用户。如果是老用户，UC登录页会自动跳转回子系统并直接登录进入首页；如果是新用户，会显示注册页，注册成功后跳转回子系统并直接登录进入。 注意：若该子系统账号注册后需要审核，则从UC登录页跳转到子系统页面后无法自动登录，仍旧需要审核通过之后才能使用该账号登录。
多次跳转时url中回调urlSon地址的完整性问题
当子系统登录页地址urlSon中含有#符号时，如果以明文传输，urlSon作为query参数，或跳转地址的url含有urlSon参数时，#后面的内容会丢失，因此需要对urlSon进行encode编码，对应地，从url中提取到urlSon后，也需要decode解码。
第三方与UC交互时url中的参数变化
前提：从第三方扫码跳转到uc时，url中会携带state参数，参数内容是子系统登录页的url和此次三方登录类型
第一次变化：从第三方跳转到uc时，第三方会自动对state参数进行encode编码 第二次变化：uc向后端以query形式发送state参数时，浏览器会自动对state参数编码
特殊变化： ①当state参数为url时，第三方只会对state使用encode编码； ②当state参数为普通字符串时，微信会使用特殊编码方式转换state，导致参数中混入&字符；另外三个仍旧对state进行code编码，但遵循RFC 2396规范，会将+转为%20，而不是W3C的空格转为+，这导致decode时将%20直接转为空格，丢失+ ③当跳转第三方时state参数已经经过了encode编码，第三方不会对state参数进行处理
最终处理方案：后端对state参数进行双重编码，前端只解码第一层使用
