1. 业务背景
按照惯例，先介绍一下业务背景。
公司有两块比较相似的业务领域，一个是统一登录，一个是三方账户绑定。
统一登录时公司自有业务渠道的登录入口，主要完成帐户登录的鉴权，包括手机号+登录密码、用户名+登录密码、短信验证码登录等。和所有网站的登录站点做的事情一样，不再赘述。
三方账户绑定是指集团其他子公司之间通过身份认证+用户授权绑定实现账户互信，账户首次绑定需要双方做登录鉴权操作，绑定之后只需要第三方账户登陆，用户便可以免登陆的情况下获得我司的登录态权限。简单业务流程如下：
注意：三方帐户绑定服务端是在三方帐户服务 thirdaccount 组件，登录鉴权场景是在统一登录服务 loginservice 组件。前端对应的静态资源也是分开在两个组件上。
2. 问题描述
可以看到‘三方帐户绑定’的过程中，需要做我司帐户登录鉴权，这里的登录鉴权和‘统一登录’场景一样，可以有多种登录鉴权方式。这两个业务场景对于前端来说，页面都类似，流程也一样。
前端同事遇到了疼点：两个相似度极大的模块静态资源存在两份，每次加入新的登录鉴权方式，都需要两边维护，成本较高，因此，前端便希望抽象出统一的页面和前端业务逻辑，配套的前端希望服务端统一提供一个登录接口，这个接口既可以做纯粹的登录，也可以做‘三方帐户绑定’，只需要多送两个：三方业务渠道（channel）、三方帐户标识（thirdAccountNo），服务端的接口判定thirdAccountNo是否有值来决定，在登录鉴权完成后，是否需要做三方帐户绑定。流程简述如下：
但是服务端不赞成这样做，服务端认为这样会造成两个独立的业务领域耦合在一起，弊大于利。矛盾在此。
延伸阅读
学习是年轻人改变自己的最好方式