决定你能不能让用户收到通知的，是用户有没有订阅，而不是有没有关注。这两个动作在平台规则里已经是两件事。
一句话结论：现在决定「能不能收到通知」的，是用户有没有完成订阅这个动作，而不是有没有关注。关注只决定通知落在哪里。
这条规则变过一次，而且很多产品还在按旧规则做设计 —— 这就是今天值得单独说一次的原因。
现象
一个很常见的困惑：「我们已经引导用户关注了公众号，为什么报告好了他没收到通知？」
答案通常不在技术侧，在规则侧：关注和订阅，现在是两个独立的东西。
拆解：一次动作，两个开关
平台对通知推送流程的说明里，有一句决定性的话（原文摘录）：
「通知的推送流程，与模板消息推送流程基本一致，只是将验证〔是否已关注服务号〕改变成了，验证〔是否已订阅通知〕。」来源：微信服务市场官方社区《合理面对风险，服务号订阅通知的正确打开方式？》，元舵核对日期 2026-09-16。
把它拆成两个开关，就能看清全部四种状态：
| 关注 | 订阅 | 能不能发通知 | 用户在哪里收到 |
|---|---|---|---|
| 否 | 否 | 发不出 | — |
| 是 | 否 | 发不出 | — |
| 否 | 是 | 能发一条 | 微信的「服务通知」 |
| 是 | 是 | 能发一条 | 服务号会话内（更显眼） |
这张表里第二行就是那个困惑的来源。
从表里还能读出两件事：
- 关注没有白做 —— 它让通知落在「服务号会话」而不是「服务通知」。前者用户天天看得到，后者藏在一个列表里。
所以关注仍然有独立价值，它的价值是「更显眼 ＋ 后续能发内容」，不是「拿到发送权限」。
- 订阅必须由用户主动完成一次，而且只能在网页里点。
一条必须知道的能力边界
平台当前的长期订阅只向特定公共服务领域开放，普通主体能拿到的是一次性订阅：订阅一次，发一条。
这意味着：用户每使用一次，就要重新授权一次。 这不是产品做得不好，是能力边界。
它带来一个直接的设计结论：
不要把「交付」压在推送成功上。 通知只是提醒；可靠的入口永远是「用户自己回来取」。一旦推送没发出去，而你的产品只靠推送通知用户，用户就永远拿不到东西了 —— 而且他自己不知道为什么。
结论
- 文案上，动词要用订阅，不要用关注 —— 用错动词的代价是：用户以为开了，实际没开。
- 界面上，可以把两件事做在一次交互里（一次点击先完成订阅、再引导关注），但不能把它做成前置条件。
- 同时必须给不想订阅的用户留一条路，例如短信。不订阅也要能拿到结果，这一条应当写进验收测试。
边界（什么情况下本文不成立）
- 本文说的是规则与机制，不是「哪家产品做得好」。关注仍然有价值，本文不建议放弃关注引导。
- 一次性订阅是当前的能力边界，可能随平台规则变化；任何据此做出的设计，都应标注核对日期。
- 网页内的订阅交互需真机调试，模拟环境不能替代 —— 涉及这条链路的验收，必须在真机上做。
你可以怎么自己验证
用两个账号各试一次：
- 账号 A：只关注，不订阅 → 触发一次通知，看是否收到。
- 账号 B：订阅，不关注 → 再触发一次，看通知落在哪里。
两次结果一对，上面那张表就在你手上了。
来源与说明
- 规则原文来源：微信服务市场官方社区《合理面对风险，服务号订阅通知的正确打开方式？》；另参见微信开放文档《订阅通知介绍》。元舵核对日期：2026-09-16。
- 「长期订阅仅对特定公共服务领域开放」为平台能力边界描述，具体适用范围以平台当期公示为准。
- 来源：元舵 Tunenomics 对外统一口径（对照复核日期：2026-09-18）。
- 本文不含客户原始数据，不含实测数字与省幅承诺。
本文为元舵「AI 行业资讯」系列。凡涉及平台规则的表述均标注了官方出处与核对日期；平台规则会变，落地前请按当期公示复核。示例数据不代表任何客户的真实结果。