1
“这里有个bug”
在选择允许订阅某一次性模版消息并且勾选“总是保持以上操作，不再询问”后，第一次模版消息触达成功；但是第二次同样的事件触发该模版订阅授权时，用户端不再弹授权弹窗，同时却没有收到该模版消息
按理说，用户已经默认允许授权该模版消息，为什么第二次触达失败了呢？
我让开发大佬查了下日志，发现微信接口返回：43101
「用户拒绝接受消息，如果用户之前曾经订阅过，则表示用户取消了订阅关系」这是接口文档的解释说明
我们又搜了微信开放社区，发现也有人遇到相同的问题，而官方的回复只是贴了接口文档的解释说明和接口文档的地址，没有其他解释；评论中也没有成功解决的案例
“这是微信的问题，我们也没办法解决。”整个团队似乎都接受了这个结论。
2
产品角度的思考
我不相信微信官方留下这个严重的问题置之不理。我把订阅消息授权和发放的接口文档仔细看了一遍，发现一个产品机制的问题：
对于一次性订阅消息，为什么每次允许授权的时候，没有发放一个唯一凭证，用于发送用户指定授权的那一条订阅消息呢？
如果有每次允许授权的凭证，可以解决两个问题：
1、每个凭证只能用一次，限制只能推送一次指定订阅消息，才符合一次性订阅消息的机制。
2、多次同类的授权事件，知道具体给哪个唯一事件推送消息。（举个抢票的例子：用户发起自动抢票时，授权抢票成功后发送一次订阅消息通知用户回来支付订单，完成购票。如果用户发起两次抢票，只授权了一次订阅消息，那么微信怎么知道用户授权的是第一次抢票事件允许消息通知？还是第二次呢？）
微信开放平台是怎么解决第一个问题的？
代入我们出现bug的场景，还有一个矛盾点：同样的授权事件，如果用户第一次允许授权通知并且勾选“总是保持以上操作，不再询问”，那么是不是以后同样的事件，无需用户授权，可以不限次数给用户推送这个模版消息呢？这不是变成永久性的订阅消息了吗？显然和一次性订阅消息是矛盾的。
那么，真相只有一个：同样的模版消息，微信是通过记录用户允许授权次数，进而限制开发者给用户推送该模版消息的次数。
解决上述矛盾点的方式就在于：虽然用户选择“总是保持以上操作，不再询问”，但是开发者还是要向微信请求该模版消息的授权获取推送次数，这对于用户来说是无感的。（官方说明：用户勾选 “总是保持以上选择，不再询问” 之后，下次订阅调用 wx.requestSubscribeMessage 不会弹窗，保持之前的选择，修改选择需要打开小程序设置进行修改。）
假设这个观点成立的。回到43101的问题，有没有一种可能是：我们没有向微信请求获取推送次数，导致后面的消息推送失败？
3
见证奇迹的时刻
我拉上开发团队的小伙伴，说出我所猜想的通过授权请求发放订阅消息次数的观点。发现大家脸上更多是疑惑和不解，意味着一开始团队里就没有人是按这个机制去设计程序的。
我把思考和推理的过程和大家讲述了一遍，我再次环视小伙伴们，有人专注在思考；有人甚至表现得有点兴奋；“我改下代码看看”，用户端的开发小伙伴直接快步走回座位
剩下的小伙伴发现新大陆般开始自发的思考和讨论我们遇到问题的可能性，其中开发还主动枚举各种用例要求测试小伙伴验证完整的功能机制。
“我调整了代码，你们重现一下那个bug”，讨论没过多久，之前离开的前端小伙伴回来打断了我们。
“你是不是获取用户选择了‘总是’和授权状态后，没有调用请求订阅消息的接口？”我直接问到。
“嗯，你们先试一下。”
“见证奇迹的时刻...”
“收到消息了！”
“我们解决了官方都没有正面回复的问题！”有人兴奋道：
4
需要完善的地方
接下来我们用各种用例测试了一遍：
用例一：A、B事件执行授权同样的模版订阅消息，A事件先允许订阅，后B事件拒绝订阅，先推送B事件的消息，然后推送A事件的消息；结果B事件的订阅消息推送成功，A事件消息推送失败，返回43101。
用例二：C、D事件授权同样的模版订阅消息，C事件先允许订阅，D事件允许订阅并勾选“总是保持以上操作，不再询问”，然后在小程序设置上修改该订阅消息状态为“不接收”，然后推送C事件订阅的消息；然后再次修改该订阅消息状态为“接收”；结果C和D消息同样推送失败，都返回43101
从用例二可以大胆推测出：用户如果主动设置不接收某模版消息，之前开发者成功获取到用户允许推送次数全部清空，后续要推送消息需要重新获取订阅消息授权
而用例一恰恰验证是上面提到微信没有下发“唯一凭证”无法解决的第二个问题。
那么接下来就是完善我们的方案了：记录每一次订阅消息的状态，推送消息时，只给当时允许订阅的事件和用户推送对应的模版消息，避免错推乱推。
另外对于选择允许订阅并勾选“总是保持以上操作，不再询问”，其实相当于永久性订阅了，因为开发者可以在用户访问期间默默的调用 wx.requestSubscribeMessage 获取消息通知次数，并使用该模版持续做业务通知。（但从产品角度上，不建议过度消费信任你的用户）
5
微信为什么这样设计
解决项目上的问题后，我尝试思考微信为什么这样设计。我把自己代入微信的角度上，很快给自己找到一个相对满意的答案
作为平台对于一次性订阅消息应当满足：
1）用户授权一次推送一次
2）避免滥用。用户授权降价通知，开发者推送新品上市，这种挂羊头卖狗肉的行为
第1点，通过发起授权发放推送次数的低成本方案巧妙解决；第2点，从产品上无法解决，只能通过审核等运营手段干预。即使是使用“凭证”，怎么用是开发者的事情，一样可以挂羊头卖狗肉。
为什么不用“凭证”，因为作为平台，没有必要解决授权和消息的一一对应关系，这恰恰是业务方需要解决的。相比之下，创造一个全新的概念比控制“次数”复杂多了。
微信这么设计没有问题，但是引导使用上有问题，毕竟“用户是没有错的”。试想如果不知道调用wx.requestSubscribeMessage是为了得到推送次数，谁又会在知道用户订阅状态的前提下调用呢？社区上遇到这个问题的开发者不在少数，又没有官方的引导解释，我相信大部分开发者会不了了之吧。
还有一个问题：为什么用户主动设置不接收某模版消息，后再次设置为接收，之前授权但还未推送的消息也无法触达了呢？文章来源：https://www.toymoban.com/news/detail-495868.html
我没有满意的答案，毕竟也是低频次的场景，不想强行解读，这个问题留给比我更执着的人吧。文章来源地址https://www.toymoban.com/news/detail-495868.html
到了这里，关于产品日记——微信小程序订阅消息踩坑43101的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
