用户反馈同一条通知收到了两遍甚至三遍，通常不是某个通道自身出了问题，而是同一条业务事件被多个入口分别推送：APP 一个通道、小程序订阅消息一个通道、企业微信应用消息又一个通道。排查的第一步不是改代码，而是先把「谁发了这条消息」找出来，再决定是收口通道、统一分发，还是靠去重键兜住。
下面按三种常见做法对比，每种都说明代价和边界，最后给出对比清单和验收项。需要结合现有系统做集成改造时，可以参考我们的软件定制开发与系统集成服务；同类交付过程见同类项目案例。
方案一：先收口触达通道，一个业务事件只走一条主通道
思路是把「发消息」收回到一个出口：业务系统只管产生通知事件，由通知服务决定这一次到底推哪儿。优先级一般按用户当前状态判断，企微在线就发企微，APP 在线就发 APP 推送，都不在线再落短信或小程序订阅消息，而不是所有通道一起发。
- 优点：重复的根源被直接去掉，用户口袋里只剩一条；运维时容易解释「消息为什么没到」。
- 优点：改动集中在推送出口，业务代码一般不需要动。
- 代价：需要一个可信的在线状态来源，企微与 APP 的在线判断口径要拉齐。
- 代价：单通道失败时补齐链路要设计好，否则会变成「少发一次」。
- 边界：适合终态类通知，比如审批已办结、工单已关闭；不适合要求强提醒的场景。
企业侧的很多重复其实来自「历史推送入口没人清理」：早期 APP 自己发，后来接了企业微信又发一次，旧代码没下掉。排查时可先按业务事件检索发送方法，把调用点列全，这一步往往就能找到第二遍消息的来源。
方案二：服务端统一分发，多通道并行但先合并
如果业务上确实需要「重要通知必须触达」，就不强求单通道，而是在中间层统一分发：同一个事件进队列，由一个分发服务同时调用企微、小程序、APP 三类推送，并对同一用户做合并，只保留优先级最高的一条即时下发。
- 优点：各端的能力差异可以继续利用，APP 推送到不了的场景由企微补。
- 优点：发送记录集中，查「谁发了什么」时不用翻三套日志。
- 代价：分发层要做队列与重试，重复消费本身就会造成第二遍消息。
- 代价：合并窗口设得太长会让消息不即时，设得太短又合不住。
- 边界：适合通知量比较大、要求跨端一致的系统；小项目上这套成本偏高。
小程序订阅消息和企业微信应用消息各有自己的调用方式和一次性额度约束，分发层建议只封装「发什么、发给谁、走哪个通道」，具体参数在适配器里处理。这样做的好处是后来换通道时不牵动业务代码，也便于逐通道验收。
方案三：多通道照发，靠去重键与幂等兜底
还有一种做法是渠道不动，每条推送带一个稳定的去重键，由各端或中间层做幂等：同一去重键在有效期内只落一次，重复到达直接丢弃。去重键一般取业务单据号加事件类型，再加一个版本或时间片。
- 优点：对现有系统侵入较小，可以先做观测再切换。
- 优点：对消息重试、网络重发这类非业务原因的重复有直接效果。
- 代价：不同端的去重仓需要统一，否则三端各自去重但用户仍会跨端看到两遍。
- 代价：不解决「同一条业务被两个模块各发一次」的起因，只是把结果挡住。
- 边界：适合过渡期，以及第三方通道不可控、只能被动接收的场景。
需要强调的是，去重只能减少用户感知，不能替代「为什么发了两次」的定位。如果起因是业务流程分支判断写错，某条件下两个分支都会执行，去重键相同还会掩盖这个逻辑错误。
什么情况下不要选这些方案
选型前先把「不该做」的情形排除掉，比急着挑方案更有价值：
- 不要在没定位重复来源之前就去重：日志和相关 ID 能还原一次完整链路，缺了这些很难验收。
- 不要只为解决重复而拆掉主通道：如果重复只出现在个别场景，改局部判断比改架构便宜。
- 不要让去重状态只存在内存里：服务重启或多实例部署后失效，问题会隔几天再冒出来。
- 不要用时间去重：比如一分钟内相同内容只发一次，正常业务的相似通知会被误吞，用户反而投诉漏消息。
- 不要把去重做成不可追溯：必须能查到「哪条被丢弃、因为什么」，否则上线后无法排查。
另外，企业微信与小程序改动往往涉及权限、类目和用户授权，涉及企业的接入审批要提前确认，不要在一次迭代中同时改通道与逻辑，否则出问题很难区分原因。
现场排查顺序：从日志到通道逐项核对
遇到「收到两遍」，建议按下面顺序推进，避免上来就猜：
- 收集用户端信息：消息内容、到达时间、来自哪个通道（企微消息、小程序订阅、APP 通知栏页面通常可辨）。
- 用业务单据号检索服务端推送日志，确认是两次发送还是发送一次到达两次。
- 有两次发送：比较两条记录的来源方法、触发流程和操作人，找共同的上层条件。
- 只有一次发送：检查重试策略、队列消费确认和客户端收货逻辑，是否重试导致同一条被多次下发。
- 两端都正常：再看前端是否自己拼了一条本地通知，与 OS 推送叠加。
逐条核对的结果要落成缺陷单，标注是哪一类重复，并约定复查方式。需要看更多系统集成与实时处理方面的做法，可以在我们的技术资料专区查阅其他专题文章。旧系统升级与重构相关的推送改造，交付流程可参考服务范围与交付流程。
常见问题与验收清单
常见问题
去重键用什么比较好？用业务单据号与事件类型组合，再加上事件触发的时间片。避免直接用消息正文或标题，内容一样的正常消息会被误判。
启用一个就可以不用另两个吗？企业微信、小程序、APP 的用户身份要能对齐到同一个人，否则去重作用不到跨端。一般建议先查清三端身份绑定关系，再谈去重。
用户手机换过还在重复怎么办？先确认旧设备或旧的免打扰订阅是否仍在使用，很多重复是同一用户挂了多个账号标识。
验收清单
- 同一业务单据在一个观察窗口内，用户各端计为一次到达。
- 推送失败可重试，且重试不会产生新的可见消息。
- 可以按单据号查到每一次下发记录：通道、时间、结果、去重判定。
- 被去重丢弃的消息有记录，可区分正常去重与异常重复。
- 通道优先级变更后，行为符合约定且原通道及时关闭。
- 单通道故障时仍有补齐手段，且有明确处理说明。
如果需要把这套收发口径固化到现有桌面与管理系统中，可以参考我们的管理系统定制与集成实施相关说明。
