小程序关联服务号推送模板消息

记录一下小程序关联服务号的消息推送功能。

准备工作：

1、获取小程序的appid与appsecret（小程序后台获取）

2、获取服务号的appid与appsecret（服务号后台获取）

3、小程序与服务号绑定在同一个微信开放平台

注意：小程序、服务号、微信开放平台都要认证！！！都要认证！！！都要认证！！！

接下来进入正题。

第一步：获取服务号的access_token

直接通过官方给的接口获取。这里有两个参数，都可以直接获取到

第二步：获取已关注服务号的所有用户的openid

还是通过官方提供的网址获取openid,这里需要一个参数access_token，已从上一步获取到了

第三步：获取已关注用户的用户信息

这一步可获取用户的详细信息，包括昵称、头像、地理位置、unionid等。根据官方网址需要两个参数access_token与openid通过上面两部均已取得。这里后台可以生成一张表用于存储这些数据。

第四步：小程序登录时获取用户的unionid

（1）用户登录小程序时，通过wx.login()获取code

（2）通过微信官方网址获取unionid，需要的参数为code、appid、appsecret

第五步：服务号的模板消息推送

（1）当服务号与小程序绑定在同一个开放平台时，他们的unionid是一样的，所以我们可以通过unionid这个中间量来进行数据的查找

（2）通过第四步获取的unionid，我们可以查找到当前登录小程序的用户他的服务号的openid。

（3）需要的两个参数都获取到了，我们就可以推送消息模板啦，接下来按照官方的教程 *** 作就行了。

（4）如果想要一次推送给多人可以把接收人的openid存到一个数组中，然后加个循环就行了。

总结：用户必须关注服务号，否则不发收到推送消息。

由于小程序只能发送订阅消息，消息类型如下：

一次性订阅消息

一次性订阅消息用于解决用户使用小程序后，后续服务环节的通知问题。用户自主订阅后，开发者可不限时间地下发一条对应的服务消息；每条消息可单独订阅或退订。（发一次消息要用户授权一下，可以同时授权多条消息提醒，但每次也只发一遍。）

长期订阅消息

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

目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放，后期将逐步支持到其他线下公共服务业务。（即使你是这些行业，也需要使用申请模板去微信那边申请。）

1、公众号和小程序需要在同一个微信开放平台下，保证拿到相同的UnionID

2、如果需要在消息模板上加上小程序的入口，需要微信公众号和小程序做关联

3、小程序和公众号都必须是认证过的

4、小程序需要提前知道公众号的appid和appsecret

5、发送消息之前需要拿到用户对应于公众号的openid（这个要前期规划好获取方案）

微信公众号会在2021-04-30发文对消息模板做限制，想要做成和小程序订阅消息一样的模式，不知道最终会调整成什么样子。

最近在做一款拼课类小程序，大概需求就是分享课程页面给好友，好友参与达到一定数量后则拼课成功。

按理说很平常的需求，微信公众号里边应该很容易实现，但是想在小程序里边实现这么个功能却有点蛋疼了。

为什么小程序实现起来比较费劲呢，那就要说下小程序发送模板消息的机制了，先看文档怎么说：

划重点， 本人 、 交互 ，也就是说这个模板消息，必须由用户手动来触发，你想后台定时给用户推个消息，洗洗睡吧你。

再来看下面：

这个重点你们自己划吧，发模板消息必须满足这两种情况中的一种，支付就不说了，用户付款后可以推送几条消息，重点是这个 表单提交 。

意思就是我想给用户发个模板消息，第一要搞个表单，第二要让用户来提交这个表单（获取formId），而且这个模板消息还只能发给提交表单的用户本人，你想发给别的用户，呵呵。

好了，说多了都是气，既然这样设计，也是有一定道理，但是道理都是讲给守规矩的人听的，至于不守规矩的，喂！说的就是你。

通过上面的分析我们知道，想发送一个基本的模板消息需要以下步骤：

模板消息接口 POST https://api.weixin.qq.com/cgi-bin/message/wxopen/template/send?access_token=ACCESS_TOKEN 有这么几个参数 ：

前面扯了一堆概念，下面我们来把这个功能具体的实现一遍吧，我这里后台用的是php laravel，原理都一样。

我这只写一个例子，一看就明白

有些时候用户 *** 作频繁，可能会导致服务器收到大量请求，所以可以优化下，把formId先存到一个全局变量里边（数组），当达到一定数量后统一发给后台来保存。这块可以灵活运用。

服务端的实现也就两个功能， 收集 和 发送 。

假设我们现在有这么一个类FormIdCollection，可以收集（save）和获取（get）某个openid的formId，那我们给前台暴露的api只需要简单的调用下就可以了，至于发消息，也只需要get一个formId，即可。

下面是FormIdCollection类的一个具体实现，基于laravel（说实话，挺好用的），另外引入了一个微信开发包 overtrue/wechat （这里主要是用来发模板消息、有点大材小用了）， https://www.easywechat.com/

我已经封装了一个laravel扩展包，感兴趣的朋友可以上github上看下 https://github.com/laravuel/laravel-wfc 。

至于非框架的php实现，小伙伴可以帮忙弄下。

---