1 背景
在依赖微信生态的 H5 应用中，使用推送提醒的运营功能，需要用户绑定微信和关注公众号才得以支撑。
因此业务方会期待，上述场景的绑定微信功能需要同时满足：业务账号绑定微信号、微信账号关注公众号。
该文档目的是：探索微信绑定和关注的不同方案，寻找较优的实现。
2 方案
注：未绑定 = 未绑定微信账号 || 未关注公众号
2.1 方案分析
方案1，先关注后绑定。借助公众号的提醒能力，来引导用户绑定微信账号
核心实现：
- 微信-生成带参数的二维码。生成绑定二维码，用于客户端展示
- 微信-接收事件推送。后端提供接口用于微信服务的调用，然后给用户发送绑定的消息
功能流程：
方案2，先绑定后关注。绑定和关注环节解耦；借助微信一次性订阅消息的能力，引导用户关注
核心实现：
- 绑定：直接在 node 层调用 sso 服务的接口进行绑定
- 关注：对未关注公众号的用户，发送一次性订阅消息，引导关注
功能流程：
状态与操作步骤情况对比
| 状态 | 方案1 | 方案2 |
|---|---|---|
| 未绑定&未关注 | 1.扫码识别，关注 2.查看公众号消息 3.访问绑定链接，登录绑定 | 1.点击按钮绑定 2.用户授权接收一次性订阅消息 3.查看消息，并关注 |
| 未绑定&已关注 | 1.扫码识别 2.查看公众号消息 3.访问绑定链接，登录绑定 | 1.点击按钮绑定 |
| 已绑定&未关注 | 1.扫码识别，关注 2.查看公众号消息 3.访问绑定链接，登录绑定 | 1.用户授权接收一次性订阅消息 2.查看消息，并关注 |
方案对比
| 方案 | 优点 | 缺点 |
|---|---|---|
| 方案1 | 1.依赖的微信能力适用范围广，早期已支持；该方案在业务的前期落地的可行性高 2.有效确定用户关注公众号的行为。关注环节先行，然后执行后续绑定 | 1.绑定和关注环节耦合。每种状态都需要用户经历完整的绑定流程 2.sso 需要业务通用，缺失鉴权登录状态，用户每次都需要输入账号/验证码完成绑定 3.完成绑定后，重定向页面只能配置一个，对业务扩展不友好(注：生成的二维码是唯一的) |
| 方案2 | 1.绑定和关注环节解耦。不同状态下，用户经历的流程不同，避免完整流程的冗余步骤，降低用户的体验压力 2.绑定环节在业务的 node 层实现。结合重定向的使用，实现绑定完成后回到业务页面，保证业务的闭环；未绑定&已关注的场景，可以实现一键绑定的效果 3.绑定前鉴权，无需重复登录 | 1.一次性订阅消息的能力，微信支持较后，每天有次数调用限制(10000000) 2.关注环节置后，无法确保用户关注公众号的状态 |
为了满足更好的用户体验，选用方案2 实现微信绑定流程。关于方案2 的缺点：
- 一次性订阅消息的能力，微信支持比较好，没有兼容问题；api 调用次数当前完全足够业务场景的使用。可以忽略
- 关注环节无法保障时，没关注的状态会显示在绑定流程的提示中，对用户有更强的引导作用
2.2 方案实现
绑定和关注环节的时序图如下所示：
定义场景值实现重定向时，同步 node 服务的处理结果到客户端。scene 的值及说明如下表：
| scene 值 | 说明 |
|---|---|
| 10001 | 绑定成功 |
| 10002 | 绑定失败，客户端 toast 提示 |
| 20001 | 一次性订阅消息-关注消息发送成功(弹框引导用户关注) |
| 20002 | 一次性订阅消息发送失败，客户端 toast 提示 |
| 20003 | 用户取消授权接收一次性订阅消息 |
2.3 实现效果对比
| 状态 | 方案1 | 方案2 |
|---|---|---|
| 未绑定&未关注 | ||
| 未绑定&已关注 | ||
| 已绑定&未关注 | 效果与第一种状态相同 |
通过上述的效果比对，方案2 体验相对友好：
- 绑定流程的环节区分明显，给用户不同的感知效果
- 冗余环节减少，可以实现一键绑定的场景，带来较好的用户体验
