我在小程序的【每日一题】中新增了订阅功能，这篇文章就来讲讲设计及开发过程中遇到的坑。
​

什么是订阅消息

消息能力是小程序能力中的重要组成，我们为开发者提供了订阅消息能力，以便实现服务的闭环和更优的体验。

订阅消息推送位置：服务通知
订阅消息下发条件：用户自主订阅
订阅消息卡片跳转能力：点击查看详情可跳转至该小程序的页面

订阅消息包括两种：

一次性订阅消息

一次性订阅消息用于解决用户使用小程序后，后续服务环节的通知问题。用户自主订阅后，开发者可不限时间地下发一条对应的服务消息；每条消息可单独订阅或退订。

长期订阅消息

一次性订阅消息可满足小程序的大部分服务场景需求，但线下公共服务领域存在一次性订阅无法满足的场景，如航班延误，需根据航班实时动态来多次发送消息提醒。为便于服务，我们提供了长期性订阅消息，用户订阅一次后，开发者可长期下发多条消息。

医疗交通金融教育

开始开发

openid

然后想到以后万一其他地方有新的订阅功能时，岂不是又要新建表？

template_id

首次测试

在页面中订阅消息，然后可以在任意时间通过服务端发送消息。

在微信的“服务通知”中成功收到消息，NICE！

于是迫不及待的又调用了一次，结果报错了，字面意思很容易理解，“用户拒绝接受消息”

{
  errcode: 43101,
  errmsg: 'user refuse to accept the msg rid: 601cebc4-6c7fee57-1d276794'
}

定位问题

一条

也就是说用户订阅后只能发送一条服务消息，如果需要再次发送，那么需要用户重新订阅。经过测试，如果用户订阅了一次后，在服务端发送消息前，用户再次订阅了一次，那么此时服务端可以向用户发送两条服务消息。也就是说用户订阅的次数是可以累加的。

那之前设计的数据库表就有很大的问题，现在无法判断是否还可以向每个用户发送消息，有可能之前已经发送过了，如果对每个用户都尝试发送，那会产生很多不必要的请求。

改进

count

count

发送消息：获取对应消息模板ID，及count值大于0的用户。发送成功后把count值减1，拒绝接受则把count置为0，其他错误则不做任何处理。

界面改进

"明日提醒"按钮最开始是设计成一直显示的，用户可以多次点击订阅，如果点击5次，那接下来的5天内，用户都会收到订阅消息。

到了第六天就会发送失败，这就会导致用户产生误解，难道是今天没发布题目吗？

为了避免这样的误解发生，当用户订阅成功后，会隐藏该按钮。

当然在进入该界面时，也需要查询用户是否已经订阅过“明日提醒”，这里我只需要判断是否有该用户订阅信息及 count 的值是否大于0即可。

自动化脚本

这个功能上线后，那必然是一个每天都要进行的任务，如果每天都手动的发送是一个相当无脑的行为。

来看看整个发送过程要进行哪些步骤吧：

第一步：获取今日题目，如果今日未发布题目，那就无需进行后面的操作，直接终止本次发送任务。并在随后每隔一小时定时执行。

第二步：获取当月的排名信息

第三步：获取当前可以发送订阅消息的用户

第四步：处理数据，这里有许多的情况，如：某个订阅用户在当月无任何打卡信息，那么他的排名应该是最后一名；每日更换“温馨提示”内容；

第五步：给符合条件的用户发送订阅消息

第六步：保存每次发送消息的返回信息，便于出现问题时定位原因

第七步：上面的步骤每天定时执行