小程序订阅消息和模板消息有什么区别？如何设计触达流程？
简化版
订阅消息是用户主动授权后，小程序才能在满足场景时发送的服务通知；它强调一次授权一次发送或长期订阅能力，不能像普通广告一样随便推。设计时要把授权时机、消息类型、发送触发条件、失败兜底和用户体验一起考虑。
详细版
订阅消息常用于订单状态、预约提醒、审核结果、物流进度等服务场景。用户必须在明确操作中授权，服务端再根据业务事件调用接口发送。
设计要点：
- 在用户最能理解价值的时机请求授权，例如提交预约后请求“到期提醒”。
- 不要进页面就弹授权，容易被拒绝。
- 前端只负责拉起授权和展示结果，服务端负责保存订阅状态和发送。
- 消息内容必须符合模板字段和平台规范。
- 发送失败要记录原因，例如用户未授权、次数耗尽、模板不匹配。
面试回答要强调：订阅消息不是营销推送工具，而是基于用户授权和服务事件的通知机制。
完整版教学
一、为什么小程序要用订阅消息
小程序不像 App 那样长期驻留，也不能随意后台推送通知。用户关闭小程序后，业务仍可能有状态变化，例如预约成功、审核完成、快递发货。订阅消息就是为这类“用户需要知道的服务结果”提供触达通道。
它的设计目标是克制打扰。平台要求用户明确授权，模板内容也要和具体服务相关。这样既保护用户体验，也防止开发者把服务通知变成广告轰炸。
用户操作 → 请求授权 → 业务事件发生 → 服务端发送 → 微信触达用户二、订阅消息和旧模板消息的核心区别
早期模板消息更偏统一模板推送，后来订阅消息强化了用户主动订阅和场景限制。面试不必纠结历史细节，但要答出权限逻辑的变化：开发者不能默认拥有推送权，必须让用户在具体场景下授权。
| 维度 | 订阅消息 | 普通站内提示 |
|---|---|---|
| 是否可离开小程序触达 | 可以 | 不可以 |
| 是否需要用户授权 | 需要 | 不需要 |
| 内容约束 | 强，必须匹配模板 | 自由度高 |
| 适合场景 | 订单、预约、审核结果 | 页面内即时反馈 |
| 滥用风险 | 平台限制较强 | 只影响当前会话 |
如果面试官问“为什么不能直接发营销消息”，答案是平台从授权、模板、类目和频次上都限制了非服务型推送，强行绕规则会影响审核和用户信任。
三、授权时机比 API 调用更重要
订阅消息的前端 API 很简单，难点在于用户为什么愿意点允许。进首页就请求“请订阅消息”，用户没有上下文，大概率拒绝；提交预约后提示“预约前 10 分钟提醒你”，用户能理解收益，授权率会明显提升。
假设首页弹窗授权率只有 8%，提交成功页授权率有 45%。同样 10000 个用户，前者只有 800 个可触达，后者是 4500 个。技术实现一样，产品时机不同，效果差 5 倍以上。
wx.requestSubscribeMessage({
tmplIds: ['TEMPLATE_ID'],
success(res) {
// res[TEMPLATE_ID] 可能是 'accept'、'reject' 或 'ban'
}
})四、服务端发送要绑定真实业务事件
前端授权成功不代表马上发送。更常见的流程是服务端记录用户、模板和业务单据之间的关系，等订单发货、审核完成、课程开播等事件发生时再发送。这样能避免“授权后立即发无意义消息”，也更符合平台对服务通知的定位。
服务端还要做幂等。比如物流状态回调可能重复推送 3 次，如果每次都调用发送接口，用户会收到重复消息。可以用 businessId + templateId + status 做唯一键，已发送过的状态不再重复触达。
订单发货事件
├─ 检查是否已授权
├─ 检查该状态是否已发送
├─ 组装模板字段
└─ 调用微信接口并记录结果五、失败处理要分类，不要只写发送失败
订阅消息失败原因很多：用户拒绝、模板 ID 错误、字段不合规、access_token 过期、服务端网络异常、用户已取消订阅。不同原因对应不同处理方式。只在日志里写“send fail”会让排查变得很痛苦。
可以按三类处理：用户侧不可达、配置侧错误、系统侧临时失败。用户侧通常不重试，配置侧需要报警，系统侧可以有限重试。这个分类能避免把拒绝授权当成异常，也能避免真正配置错误被海量日志淹没。
| 失败类型 | 例子 | 处理 |
|---|---|---|
| 用户侧 | 拒绝授权、次数耗尽 | 记录即可 |
| 配置侧 | 模板字段不匹配 | 报警并修配置 |
| 系统侧 | token 过期、网络超时 | 刷新或重试 |
六、触达流程要兼顾隐私和体验
订阅消息涉及用户触达，不能只从“转化率”出发。文案要明确告诉用户订阅什么、什么时候发、有什么价值。不要用模糊的“开启通知获得更多服务”，这会让用户产生防备。
同时要减少重复打扰。用户拒绝后可以继续提供页面内提醒或短信等可选方案，但不应每次点击都强行弹授权。较好的做法是记录本次业务的授权结果，在关键节点给一次解释充分的机会。
易错点：订阅消息的难点不是调起弹窗，而是让授权、业务事件、模板内容和失败处理形成闭环。
七、常见误区与追问
- 误区：用户点过允许后就能无限发送。 多数服务通知受授权次数、类型和平台规则约束，不能当作无限推送通道。
- 误区：首页越早弹授权越好。 没有业务上下文时用户不理解价值，拒绝率通常更高。
- 误区：前端授权成功就代表发送一定成功。 发送还依赖服务端 token、模板字段、用户状态和平台校验。
- 追问：如何提升授权率？ 在用户完成相关动作后说明具体收益，例如预约提醒、发货通知、审核结果。
- 追问：发送失败要不要重试？ 用户拒绝类不重试，网络和 token 类可有限重试，配置错误要报警。
- 追问：订阅消息能做营销吗？ 不应作为营销通道，内容必须符合服务场景和模板规范。
八、加强记忆
订阅消息用“场景授权、事件触发、模板发送、结果闭环”来记。前端负责在合适时机请求授权，服务端负责和真实业务事件绑定，发送结果要分类记录，用户拒绝也要有体验兜底。面试时把它从一个 API 扩展成一条触达链路，回答就会明显更完整。