我已经踩过坑了，补充一下其它的看法。

按照目前的机制，如果是把旧的模板消息一刀切砍掉的话，一次性订阅消息满足不了大部分想要做推送消息的开发者的需求，每次都弹出订阅消息授权，会让用户直接取消，除非是刚需的通知。

还有就是可选的订阅消息的模板内容和原来的模板消息比起来局限性太多了，受制于类目的要求，使很多模板无法申请。

40岁以上的大叔大妈 , 根本不懂操作 , 有些东西太人性化 , 往往增加学习难度

他们会说:

什么是订阅阿?

要怎么订阅阿?

哎呀,这小程序也太难用了, 这要点,那要点

@!#@%!@%

坚决反对取消模板

1、一次性订阅的场景还是不够用，希望尽快开放全类目的长期性订阅；

2、支付后给用户一个订单推送应该很刚需吧，不需要再询问一遍用户是否订阅吧？类似这样的场景，可不可以给一次免询问的推送机会？

3、我们的用户群体是农民工，很多低端手机和低版本的微信，有的是不会升级，有的是不愿意升级（怕卡顿或者数据丢失），还有的是ios不知道apple账号密码导致无法升级的，模板消息如果停掉的话，相当一部分的用户会“失联”，可以的话希望能保留模板消息的功能，或者至少在低版本保留这一功能。

首先谈一下目前的接口：wx.requestSubscribeMessage(Object object)

这里动态的键不合理吧，希望改为更容易代码处理的JSON格式。例如：

下面结合我们目前的需求：维修报障工单，我们的员工发现了故障设备，通过小程序创建维修工单，维修组有若干个维修人员，然后有一个负责人进行任务分配到具体一个维修人员处理，维修人员处理完成需要通知报障人处理结果，然后报障人进行满意度评分。

这里的场景，我们的维修人员需要一个长期订阅的任务通知消息由维修组的负责人触发，报障人需要一次性订阅消息2条：维修任务已受理，维修任务已完成。

但是目前长期订阅消息还是没有可选模板。

我觉得为何不把主动权交给用户，在用户使用某个功能页面的时候，就直接调用长期订阅接口，询问这几个模板提示是否接收，具体用途是什么，跟定位询问一样。在用户接收到推送的模板消息后(服务通知显示)，可以随时进行退订。也可以在右上角点击...按钮，随时订阅或退订。

一次性订阅我觉得没有必要，就保留长期订阅就可以了，这样不是皆大欢喜吗？

我是支持这个产品决定。

1无缘无故的索要用户信息被上次登录整改整掉了。

2 不明的推送通知消息这次被干掉了。

我是很赞成小程序这俩举动。虽然，这会对某些产品的原始设计是冲突的，但作为微信公民来看这样的设计是很人性化的。太多的不明场景所要身份信息，各种无用的通知打扰，严重占用我没没必要的精力。不管对微信公民还是对微信环境都是不好的。生态要友好，长期发展，一定要站在终端用户的角度去想问题，才能做出符合人性有价值的产品。建议产品经理要理解，微信小程序产品每个大的看似限制的举动背后的意义。以上思维来高级产品总监的课程学习，共勉~

愿我们从终端用户的角度去理解生态，设计产品，公赢~

1、限制消息类目的申请，对开放平台模式下的服务商来说是个很不友好的限制

2、很多用户都不知道怎么操作的，之前已经产生习惯从推送里面回到小程序内，增加用户的成本

3、开发者为了拿到更多给用户发送订阅消息的次数，肯定会想方设法去埋点引诱用户去点击，从而获取次数，用户不关闭就没法做下一步操作。

4、用户误操作的成本很高，比如一个到店预约的服务，原来的场景是用户只要有提交表单或者下单，开发者就可以用户推送提醒，但是现在还得用户去点击订阅消息，这样多了一步，如果用户不懂得去点击订阅消息或者点了取消，不同意推送，开发者就没法通知到用户了，用户可能因此错过了服务，然后造成客诉，影响巨大。

整体来说微信的出发点是好的，但是有一些地方直接一刀切确实很难让开发者跟用户立马适应起来，有些方面是好的，比如用户知道自己将会收到什么推送，有些确实很不适合这样直接改掉，比如上面说的预约类型的，用户误操作的成本巨大。

虽然我们在这边怎么BB都没用，最终也只能跟着微信的节奏走，毕竟我们在体系内，得遵守规则制定者制定的规则，但是相信微信是为了更好的用户体验在做这些优化的。

所以以上我说的都是废话，跟着改就对了，不改也得改。

有考虑过用户群体吗，用户都是白痴，多点一下都嫌麻烦，你这叫用户体验？还有主营业务在三线城市以下的，4s都能一天给你拿几台出来，即使是6s，大部分iOS用户连个app store都不知道的你让他升级微信？？点了升级微信app store转不开啊，有办法？你自己微信先去解决这个iOS用户升级问题吧

作为一个第三方模板小程序服务商角度回答一下这个问题。

1. 先说模板消息，第三方服务商可以通过调用服务端API快速管理（CRUD）模板消息，但是模板消息有7天内的有效的时间限制，并且在用户提交信息时，每次都要记录对应的formId和过期时间以及对应的使用次数（支付的prePayId产生的formId可以使用3次），最大的问题在于7天的时间太死，并且使用次数也很死，例如场景：订单售后退货有时候会延时很久，购物车商品降价通知无法实现；

2. 再说说订阅消息，时间不再限制，很不错，但是次数还是没有解决问题，例如场景：订单下单之后状态变化可能有待支付超时通知，发货通知，待评价通知等等，但"目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放，后期将逐步支持到其他线下公共服务业务"还是把行业服务类目限制死了，感觉不会再爱了，好么？

微信已经向官僚体系方向发展了？在没有充分论证订阅消息的情况下，以长官意志为考虑问题的出发点，不考虑整个生态圈各方的利益，就把一个完全不成熟的订阅消息推出来了？虽然我对模版消息也不是很满意，但是这个订阅消息实在太令人失望了。生态圈要建立起来千难万难，但是倒下却是分分钟钟的事情，希望微信在消息系统这样一个关键模块的改革上，能够更加的慎重，不要让官僚体系毁了小程序。

个人感觉，还是比较合理的。能够明确收到提醒，要给你发一条信息是否允许。

不足之处在于，对于绝大多数条目仅能发布一条信息。

希望能根据情况，在审核通过的情况下，允许发布多条信息。

我目前的解决办法是，在最外层的view上面加了bindtap，因此用户几乎任何操作都会提醒接受一条消息，直到程序认为自己获得的通知累计数量达到要求。

用户会收到多次提醒，我相信多数用户会在几次提醒后受不了，点击下方的以后直接同意，不用提醒。这样以下就可以在静默状态下收集提醒次数了。