做小程序的客户，十个里有八个要「下单之后给用户发个通知」。听起来是个小活，真到API接口对接的时候，问题一个接一个冒出来。把被问得最多的六个问题整理出来，开工前先看一遍，能省两轮返工。
问题一到三：基础三连
- access_token要不要存？要，而且必须存。它两小时过期，每次都现领还会互相顶掉，得放缓存里统一管理，谁要用谁去取。
- openid和unionid啥区别？openid是用户在你这个小程序里的编号，unionid是同一主体下多个应用的通用编号。以后要打通公众号或APP的，一开始就得按unionid的路子设计，后补起来很麻烦。
- 模板ID哪里来？小程序后台的订阅消息模块里自己申领，选类目相关的模板。参数格式有硬性要求，日期就得传日期格式，自由发挥会被拒审。
问题四到六：踩坑三连
- 为什么有的用户收不到？订阅消息是一次授权发一次。用户点了「总是保持以上选择」才能长期收，否则每次下单都得拉起授权弹窗，用户一旦拒绝，通知就发不出去，这属于产品逻辑，不是bug。
- 发多了会被限吗？会。接口有频率上限，营销轰炸式的发送还可能被封模板。正常业务通知一般够用，别拿它当群发工具。
- 点通知能跳到指定页面吗？能，page参数里带上路径，比如直接跳订单详情。路径写错了通知照样发出去，用户点开是个空白页，这种细节测试时千万别漏。
再多说一个容易被忽略的点：通知文案本身就是转化工具。同样一条发货通知，「您的订单已发货，点击查看物流」和「您的宝贝已出发，预计后天到达，点击查看物流」，后者的点击率明显更高。模板参数允许的话，把预计送达时间、订单金额这些用户关心的信息带上，通知才不只是个提醒，还是一次免费的召回。
开工前再啰嗦两句
说两句实在的：这类通知功能别自己埋头硬写，官方有现成的示例代码，难点在产品逻辑而不在代码。另外找外包做小程序时，问一句access_token存在哪、用户拒收后有没有引导重新订阅的方案，答不上来的团队多半是现学现卖。比格网络常年做小程序开发，这类API接口对接的问题在开工前就讲清楚了，沟通成本会低很多。
