本文是我的小程序开发日记的其中一篇， GitHub 原文地址 欢迎star，感谢万分！
前言
小程序的早期定位是“即用即走”或者说是“用完即走”。
但小程序的运营者却不是这么想的，希望用户尽可能的停留在小程序上，或者“多回来看看”，俗称“拉回流”。
让用户回流的关键手段就是 订阅消息，通过点击订阅消息，可直接回到小程序。
背景
早期小程序提供的是 模板消息，用户每次点击或者完成支付，都会生成一个formId或者paypay_id，开发者可以通过这个formId给用户发送一次模板消息。
因此，开发者的常规做法：尽可能地在每个按钮上都封装form，用以收集formId；收集的formId并不会使用，而是将它们存到数据库里，在需要拉回流的时候，通过这些formId发送模板消息。
这样会存在几个问题：
- 用户会被莫名的骚扰（因为
formId有7天的有效期） - 用户收到的模板消息是无预期的（因为
formId可以发任意的模板消息） - 开发者在每个页面每个可点击区域都封装了
form，导致代码混乱
为了解决以上问题，小程序团队就采用了 订阅消息 来替换 模板消息。
小程序模板消息接口于2020年1月10日下线
订阅消息的优势
订阅消息 与 模板消息 相比较，明显的优势：用户对自己将收到的模板消息类型有一定的预期，如：
另外，对订阅消息的发送时限不做限制，即可以在任意时间给用户发送一条模板消息，而不像以前的formId有7天的有效期。
从开发者的角度看：订阅消息是使用接口调用(wx.requestSubscribeMessage)，不再是以前那样，一定要用Button。对于代码维护和开发效率来说，都是利好的。
从代码维护上讲，开发者不用再层层嵌套form了，简化了许多代码；另外，以前模板消息是通过Button封装的，拜托了这层束缚之后，就不用再重置Button的样式了，对于开发效率也是有一定的帮助。
模板消息
<form bindsubmit="addFormId" report-submit>
<button class="invite-btn" form-type="submit">
邀请好友
</button>
</form>
Page({
data: {},
addFormId(e) {
let { formId } = e.detail;
// save formId
}
})
订阅消息
<view class="invite-btn" bindtap="handleInvite">邀请好友</view>
Page({
handleInvite() {
wx.requestSubscribeMessage({
tmplIds: [''] // 订阅的模板ID
})
}
})
但是，订阅消息仍有个小程序通病，有一定的兼容性，需要基础库2.4.4以上才能使用。这也就意味着，2020年1月10日模板消息下线之后，你没法招回停留在基础库2.4.4以下的用户了。
订阅消息的类型
以往的模板消息，每次发送消息需要消耗一个formId，而formId有7天的有效期，因此小程序无法召回7天以前的活跃用户。
而订阅消息则提供了两种类型：
- 一次性订阅
- 长期订阅
其中，一次性订阅与以往的模板消息类似，是一次性的，唯一的差异是订阅消息没有限时；而长期订阅则是召回的利器，用户只要订阅过一次，小程序将获得给该用户发送多次消息的能力。
不过，目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放。而且个人主体的小程序没有权限申请。
开发的差异
小程序端
以往的模板消息方式，需要前端将每次收集到的formId，上传至后端保存起来。现在，需要做的是，记录一下哪个用户订阅了哪些模板即可，至于订阅的次数，也是需要开发者自行保存的。
另外每次发起消息订阅，都会有弹窗出现：
用户可以勾选“总是保持以上选择，不再询问”，这样下次点击时，就直接授权订阅。
若此后希望小程序重新出现弹框，则是没有办法的。只能在设置页里取消单个订阅消息，或者关闭接收所有订阅消息：
其实就等于将这些设置转移到更深的路径上，但还是保留了用户取消订阅的权利。
如果用户关闭接收所有订阅消息，那么调用wx.requestSubscribeMessage时，会触发fail，并返回如下信息：
{
errCode: 20004,
errMsg: 'The main switch is switched off',
// 用户关闭了主开关，无法进行订阅
}
总结
订阅消息是模板消息的进阶产品，对于用户、开发者更友好，但对于小程序的运营者来说，反而并没有更大的帮助。毕竟以往formId的方式，可以用来发送任意模板消息，现在只能“特定订阅特定使用”。
因此，更多的小程序运营者会讲小程序的用户引导到公众号，这样才能更大可能地接触到用户，毕竟公众号的消息推送更不受限制。
强力驱动