消息通知为什么总漏发或重复？事件、订阅与发送回执设计指南

订单已发货却没收到提醒，审批已完成却连续推送三次，都是企业系统常见的体验问题。消息通知不是在业务代码最后调用一次发送接口，而是需要区分发生了什么、通知谁以及最终送达了没有。

一、先区分业务通知和营销触达

付款结果、审批待办与促销推荐的紧急程度及用户预期不同。混用同一模板和发送频率，容易让重要消息被淹没，也难以落实用户对不同类型通知的选择。

按照业务用途分类，写清触发条件、接收人和允许渠道。用户授权和平台模板能力以实际接入渠道规则为准，不把一次服务通知许可理解成可以无限发送所有营销消息。

二、不要依靠页面操作触发重要消息

如果只在用户看到成功页面时发送提醒，页面提前关闭或网络断开就会漏发。后台修正状态或自动处理的订单，也可能绕过这个页面入口。

由已经确认的业务事件产生通知任务，保存事件编号与关联对象。订单状态先有可信记录，消息失败不倒转已完成交易；详情页始终能查到事实，不以用户是否收到消息判断业务是否发生。

三、接收人规则也需要快照

审批流启动时的主管和真正发送时的主管可能不同。全部实时读取当前关系，会让接任人收到旧提醒；全部固定又可能在原负责人离职后将消息发给无人处理的账号。

按通知类型区分历史告知和当前待办，记录接收依据。发送前校验账号有效性，待办转交走正式流程；群发名单预览包含人数和范围，不让一条部门配置变化意外扩大接收对象。

四、发送任务要能承受突发量

集中导入订单或月底批量生成账单时，短时间可能产生大量通知。所有业务请求同步等待发送，会拖慢交易流程，渠道限流又会导致更多请求失败。

将通知放入受控队列并限制发送速率，观察积压与最老任务等待时间。队列可以缓冲突发负载，但不能保证消息无限期最终成功，仍需容量边界、失败处理与责任人。（参考：Microsoft Learn：基于队列的负载均衡）

五、受理成功不一定实际送达

渠道返回接受请求，可能只是进入对方处理队列。发送到失效账号、设备关闭通知或模板被拒绝，都可能使用户没有看到内容，不能把一次接口成功当成已读。

分别记录待发送、已受理、送达失败及平台能够提供的其他状态；没有送达回执时明确标为未知。业务待办以是否处理为准，必要时通过授权渠道补充提醒，不伪造已读状态。

六、去重与补发使用同一业务依据

自动重试、人工补发和重复事件可能同时发生，若各自生成新的通知标识，用户就会收到多份同样内容。过度去重也可能吞掉确实发生的第二次状态变化。

用事件、通知类型和接收对象形成去重依据，保留重试记录。状态真正变化产生新事件，人工补发说明原因并受频率限制；营销取消订阅后不得借补发入口重新发送。

七、验收时看漏发和误发两种风险

系统能发出一条消息，只证明最简单路径可用。真正需要检验的是重复事件不轰炸用户、失败有原因、权限变更不误发，以及渠道短暂不可用时业务本身仍能继续。

构造重复事件、失效接收人、模板拒绝和渠道限流样例，检查重试上限与待办接管。报表同时统计发送量、失败原因和积压，避免只用发送成功率掩盖错误接收范围。

上线前检查清单

1. 01　业务营销通知分开
2. 02　服务端事件驱动任务
3. 03　接收范围有依据
4. 04　发送有队列与速率限制
5. 05　受理送达已读不混淆
6. 06　重试补发遵守统一去重
7. 07　关闭订阅能够生效
8. 08　漏发误发积压均可追查

武汉米能科技有限公司以“米能软件”对外提供APP、微信小程序、企业管理系统与AI应用定制开发。项目先确认业务边界、资料基础与验收样例，再确定实施范围和技术路线。具体功能、交付周期、数据权限及维护责任以双方确认的方案和合同为准。