小程序下单提醒，用户明明点了允许，为什么后面还是收不到？

结论先行：小程序下单后用户收不到提醒，多数不是小程序「坏了」，而是订阅消息的三件事没对齐——授权类型（一次性还是长期）、发送时机、模板类目与参数。用户点过一次「允许」不代表长期有效，一次性授权用掉一次后再下发，系统往往静默失败，页面上什么都不显示。按 2026 年常见做法，先查后台发送记录和用户授权状态，再核对模板是否合规，能排掉大部分「通知发不出去」的问题。

一、小程序里的「提醒」，其实有好几条链路

很多需求方口中的「推送」，在技术上至少对应四条不同链路：订阅消息、公众号服务通知、短信、站内提示与客服消息。它们的触发条件、用户同意方式和到达率差别很大，混着说就容易出现「我以为发了，用户说没收到」。交付时我会先确认三件事：这条提醒走哪条链路、由谁触发、用户在哪一步被要求授权。这三点不写清，后面所有排查都是猜。

• 订阅消息：用户主动点「允许」后平台才允许下发；一次性授权一般对应一次下发机会，长期订阅只在少数类目开放，能否申请以平台规范为准。
• 公众号服务通知：依赖用户是否关注公众号，与小程序登录态不是一回事，能触达的人数通常更少。
• 短信：不依赖小程序生态，到达相对稳定，但要走签名与模板报备，按条计费。
• 站内提示与客服消息：角标、订单页状态、客服回复，只解决「用户已经进来」之后的问题，适合当兜底。

二、用户点了「允许」，为什么后面还是收不到

遇到提醒不到，建议按「四步核对法」从后端往用户手机倒着走，而不是一上来就改代码。顺序反了，容易在没问题的地方反复改，白耗工期和预算。

1. 第一步，看发送结果：后台或日志里这条消息是「成功下发」「被拒绝」还是根本没触发。没触发多是业务代码没调用；被拒绝则指向授权或参数。
2. 第二步，看用户授权状态：用户点的是「允许」「拒绝」，还是勾了「总是保持以上选择」。一次性授权被消耗后再下发就会失败，这类静默失败在项目里反复出现。
3. 第三步，看模板与参数：模板是否已下架或类目变更、参数字段是否超长、是否夹带不允许的文案，参数类型对不上也会直接失败。
4. 第四步，看用户侧设置：手机系统通知权限是否被关、是否开了免打扰、用户是否手动关过小程序消息接收。这一层不归开发管，但要写进交付说明。

做到什么算合格：能用一条测试消息把四步完整走通，并留下后台截图或记录；参数映射、授权设置、异常降级都有书面说明。只靠开发口头说「我这边是好的」，不算通过验收。

三、提醒方式怎么取舍：一组可核对的对比

选提醒方式没有标准答案，看的是触达必要性、成本和打扰之间的平衡。下面这组对比按项目交付习惯整理，数字是经验区间，具体仍要以平台官方文档和类目规范为准。

• 订阅消息：开发成本低，常见区间是几个工作日接入；到达率取决于用户是否授权，多为一次性；适合订单状态、核销这类强动作场景。
• 短信：到达相对稳定，按条计费，常见区间是每条几分到一毛多；验证码、支付结果这类需要送达的通知更常用，营销类短信还需单独报备。
• 公众号服务通知：前提是用户关注了公众号，触达人群有限；适合已有公众号运营体系、需要图文引导的情况。
• 站内提示加客服消息：几乎零成本、打扰小，但只在用户主动进入小程序时有效；适合兜底，不适合当主通道。

按移动端定制交付的常见做法，是「订阅消息打头阵 + 短信兜底 + 站内状态自检」。但兜底要不要上，看单条通知的业务价值：一条订单确认值不值得花短信费，算一次就能定。这一步通常写进需求确认单，避免上线后再临时加通道、重走报备流程。

四、适用与不适用边界

适合做完整提醒体系的情况：订单、支付、预约、核销这类有时效要求的流程，用户需要在特定时间点回来；客服被「状态咨询」压着；业务已通过类目审核，能申请到对应的订阅模板。

不必上提醒体系的情况：纯展示型或内部工具型小程序，用户本来就主动访问；用户量很小、运营节奏慢，人工客服回复更快更省；以及暂时没有精力持续维护模板与文案的场景——模板下架、类目变更后没人跟，提醒会静默失效，比不做更糟。这条边界建议在立项时就写清，而不是上线后再补。

五、交付现场：预算紧、周期短时怎么排

一个常见约束是：预算有限、上线只留了两三周，需求方却希望把所有通知一次做全。常见做法是先只接「订单状态」一条链路，把授权请求放在用户下单成功那一刻，其余通知留到二期。代价是后续每加一条通知，都要重走授权引导和模板核对，改稿次数会明显增加，所以一期就要把后续要接入的模板名提前列进需求文档。经验区间上，预留一到两天专门做通知联调比较稳；只留半天，往往就是上线当天才发现授权已经被用掉。

常见问题

用户点了一次「允许」，为什么后面就收不到了？

一次性订阅的授权一般只对应一次下发机会，用掉即失效。需要多次提醒时，应在用户每次触发业务动作时重新请求授权，或改用长期订阅类目，能否开放以平台规范为准。

后台显示发送成功，用户还是说没看到，算谁的问题？

发送成功只代表平台已受理，不代表已经展示。常见原因是用户手机通知权限被关、开了免打扰，或消息被折叠进服务通知；验收时把用户侧设置也纳入核对清单更稳。

订阅消息的模板可以自己随便写吗？

不可以。模板要从平台提供的类目模板里选用，字段名和取值格式都有约束，文案也不能带营销诱导。常见做法是先用平台模板跑通，再在允许范围内调整措辞。

提醒功能写进合同，怎么判断有没有做到位？

看三件事：测试消息能完整走通、参数与模板有文档记录、异常情况（授权被拒、参数超长）有降级方案。条款只写「支持消息推送」几个字，验收时基本无法核对。

用短信兜底，成本会不会失控？

短信按条计费，经验区间是每条几分到一毛多，量大时值得做频控和去重；常见做法是只对高价值节点发短信，其余交给订阅消息和站内提示。

如果你正在做小程序，先别急着加推送功能：把「哪条通知需要送达、用户在什么时候授权、失败了怎么兜底」写进需求文档，再决定上哪几条通道。涉及类目、模板和授权规则的部分，按平台官方文档和交付验收清单逐项核对。用户量小、节奏慢的项目，把客服回复做顺，往往比搭一套提醒体系更划算。