研发通知重复发送通常集中在四个环节：事件源重复触发、通知规则与订阅重叠、投递重试与接收端幂等缺失、连接与账号重复绑定。排查时先确认重复的形态，再沿“事件源—规则—投递—接收”逐段取证，定位后通过去重键、幂等消费、规则合并和订阅清理处置，并用一段时间的发送日志验证是否复发。
要点总览（TL;DR）
- 研发通知重复发送集中在四类原因：事件源重复触发、通知规则与订阅重叠、投递重试与接收端幂等缺失、连接与账号重复绑定。
- 先按同内容同时间、同内容不同时间、不同渠道各一份三种形态归类，再收集渠道、时间戳、事件对象、接收人范围等取证信息。
- 排查按“发送日志与事件ID—规则与订阅清单—重试与幂等—授权与身份清理”的顺序推进，每步设停止点，修改前留存原配置。
- 处置后用相同口径的发送日志对比处置前后重复率，并构造一次测试事件确认每个渠道只收到一条通知。
- 长期预防靠统一事件去重键、规则归口管理、订阅定期清理和通知配置变更前评审。
重复通知长什么样：先分清三种形态
“重复发送”在现象上并不只有一种。先按形态归类，能大幅缩小排查范围，避免一上来就翻配置。建议从接收侧收集最近若干条重复通知的原始记录，按内容、时间、渠道三个维度比对。
三种典型形态
| 形态 | 典型表现 | 初步指向 |
|---|---|---|
| 同内容、同时间多条 | 同一事件在几秒内产生两条以上通知，内容与时间戳几乎一致 | 一次事件被多次投递，问题多在事件源或投递环节 |
| 同内容、不同时间多条 | 同一事件的通知间隔数分钟甚至更久再次出现 | 投递超时重发、消费失败重放，或定时任务重复执行 |
| 不同渠道各一份 | 邮件、即时消息群、工作项评论各收到一条，内容相同 | 多渠道订阅叠加，同一事件命中多个通知出口 |
三种形态可能同时出现。例如一次合并请求变更既触发了邮件规则，又通过群机器人推送，同时因投递超时被重发一次，接收方就会看到跨渠道加同渠道的多份通知。归类时按“每条通知单独打标签”的方式记录，比笼统统计“重复了几次”更有用。
取证清单
在动手改配置之前，先把以下信息收集齐，后续每一步排查都要靠它对照：
- 通知渠道：邮件、即时消息、群机器人、站内提醒、Webhook 回调等，分别记录。
- 时间戳：精确到秒，保留原始时区，便于判断是否落在同一投递窗口内。
- 事件对象：对应的代码提交、合并请求、工作项、流水线运行等唯一标识，例如提交哈希、合并请求编号、工作项 ID。
- 接收人范围：是单个成员重复收到，还是整个群、整个项目组都重复收到。范围不同，指向的原因也不同。
- 触发来源：通知正文中通常带有触发动作描述，记录是“状态变更”“评论”“指派”还是“定时提醒”。
这份清单同时是后续验证的基线。处置完成后，用同样的口径再采一轮数据，才能判断重复是否真的消失。
按链路找原因：事件源、规则、投递、接收四段假设
研发通知的完整链路是：业务事件产生 → 通知规则匹配 → 投递到渠道 → 接收端呈现。重复可能发生在任何一段，也可能由多段叠加。下面按段列出原因假设，每条假设都配可验证的证据，避免把猜测直接当成结论。
事件源重复触发
同一业务变更被系统识别为多次事件，是最容易被忽略的一类原因。常见情形包括：代码托管平台的 Webhook 在推送失败后自动重发；同一合并请求因多次推送提交而反复触发“更新”事件；工作项在一次保存中被拆成多个字段变更事件分别发出；流水线重跑或定时任务重复执行，导致同一结果被多次上报。
验证证据：查看事件源侧的投递记录或 Webhook 日志，确认同一事件标识是否出现多条推送记录，以及这些记录的间隔是否符合平台的重试策略。排除条件：事件源侧只有一条推送记录，而下游出现多条通知，说明问题不在事件源。
规则与订阅重叠
同一事件同时命中多条通知规则，或多个订阅者各自订阅了同一事件，接收方就会收到多份内容相同的通知。典型场景：项目级规则和仓库级规则都配置了“合并请求创建时通知”，两条规则同时生效；一个群机器人被多个项目重复绑定；某成员既在个人订阅中关注了该工作项，又在项目默认通知人中；集成应用与内置通知各推送一次。
验证证据：导出当前生效的通知规则清单与订阅清单，按“事件类型 + 对象范围 + 接收目标”三个字段做交叉比对，找出指向同一接收目标的重复条目。排除条件：清单中每个事件类型只对应一条规则、一个接收目标，则重叠假设不成立。
投递重试与幂等缺失
投递环节的超时重发是“同内容不同时间”形态的主要来源。当接收端响应慢或返回错误，发送方按重试策略再次投递；如果接收端没有按事件 ID 去重，就会把重试当成新通知展示。消费失败后的消息重放、队列积压后的补偿发送，也会产生类似效果。
验证证据：对照发送日志中的重试记录与接收侧的通知时间戳，看重发的通知是否携带相同的事件 ID；检查接收端是否实现了基于事件 ID 或去重键的幂等处理。排除条件：发送日志显示每条通知只投递一次且无重试记录，则问题不在投递段。
连接与账号重复
同一应用被重复授权、同一成员存在多个身份、同一机器人被重复绑定，都会让一条事件被多个连接各处理一次。常见情形：集成应用在多个项目空间分别安装并各自订阅；成员离职后重建账号，旧账号的订阅未清理；群机器人在迁移群聊后新旧绑定同时存在。
验证证据：检查应用授权列表、成员身份列表和机器人绑定列表，确认是否存在指向同一对象的多条记录。排除条件：每个应用、成员、机器人在清单中只有一条有效记录。
原因假设对照表
| 原因假设 | 可能表现 | 验证证据 | 排除条件 |
|---|---|---|---|
| 事件源重复触发 | 同内容同时间多条，间隔符合平台重试节奏 | 事件源投递日志中同一事件标识出现多次 | 事件源侧仅一条推送记录 |
| 规则与订阅重叠 | 不同渠道各一份，或同渠道固定多份 | 规则与订阅清单交叉比对出现重复条目 | 每个事件类型仅一条规则、一个目标 |
| 投递重试与幂等缺失 | 同内容不同时间多条，间隔为分钟级 | 发送日志有重试记录，接收端无去重逻辑 | 发送日志无重试，接收端按事件 ID 去重 |
| 连接与账号重复 | 按项目或按身份成组重复 | 授权、身份、机器人绑定清单存在重复记录 | 清单中每个对象仅一条有效记录 |
实际排查中，四类原因常常叠加。例如规则重叠导致两条投递，其中一条超时重试，最终接收方看到三条。因此验证时要逐段确认，不能因为找到一处重叠就停止排查。
排查顺序与处置动作
排查顺序建议从证据最完整、改动成本最低的环节开始，逐步向影响面更大的配置推进。每一步都设一个停止点：证据足以确认或排除该段原因后，再进入下一段。
第一步：查发送日志与事件 ID
从发送日志入手，按事件 ID 聚合通知记录，确认重复发生在哪一段。如果同一事件 ID 在日志中只有一条发送记录，而接收方收到多条，问题在接收端展示或渠道侧；如果同一事件 ID 有多条发送记录，继续看这些记录的触发来源是规则匹配还是重试。
这一步的停止点：能明确回答“重复发生在投递之前还是之后”。在此之前不要修改任何规则配置。
第二步：核对通知规则与订阅清单
导出全部生效规则与订阅，按事件类型和接收目标做交叉比对，合并指向同一目标的重叠条目。合并时保留覆盖面更完整的一条，删除或停用冗余条目。对于多渠道叠加的情况，先确认业务上是否确实需要多渠通知，再决定保留哪个渠道。
风险边界：停用规则前先确认该规则的影响范围，包括它服务的项目、成员和事件类型；修改前留存原配置的导出副本，便于回退。
第三步：检查投递重试与接收端幂等
查看投递侧的重试次数与超时设置，判断重试是否过于激进；同时检查接收端是否按事件 ID 或业务唯一键做去重。接收端由外部系统承载时，去重逻辑需要对方配合实现，本文只能给出通用要求：同一事件 ID 在有效窗口内只处理一次。
风险边界：调整重试参数会改变故障时的送达可靠性，降低重试次数可能让瞬时失败的通知彻底丢失。修改前记录原参数，并在测试环境验证一次失败重试场景。
第四步：清理重复授权、机器人与身份
按清单逐项清理：解除重复的应用授权，保留仍在使用的那个；合并或停用重复的成员身份，迁移其订阅关系；解绑重复的群机器人，确认保留的绑定指向正确的群聊。
风险边界：解除授权和停用身份会影响该连接上的全部通知与集成动作，操作前确认没有其他业务依赖该连接；清理动作建议分批执行，每批之后观察一轮通知是否正常。
处置路径与回退方式
| 步骤 | 动作 | 停止点 | 回退方式 |
|---|---|---|---|
| 1 | 按事件 ID 聚合发送日志 | 确认重复发生在投递前还是投递后 | 只读操作，无需回退 |
| 2 | 合并重叠规则与订阅 | 每个事件类型仅保留一条有效规则 | 导入修改前的配置副本 |
| 3 | 调整重试参数、补齐接收端去重 | 测试环境验证失败重试场景通过 | 恢复原重试参数 |
| 4 | 清理重复授权、机器人与身份 | 每批清理后观察一轮通知正常 | 重新授权或恢复绑定 |
在通知规则与订阅的管理上，ONES 可以承载工作项事件的通知配置，把规则、接收人和通知渠道集中在一处维护，减少项目级与仓库级规则各自配置造成的重叠。具体的管理入口与配置项以产品实际界面和官方文档为准。
如何验证恢复并防止再次发生
处置完成不等于问题解决。需要用数据确认重复率下降，再用机制防止同类问题回流。
用日志对比处置前后
选取处置前后各一段相同长度的时间窗口，例如各三天，按事件 ID 统计“每个事件对应的通知条数”分布。处置前若存在大量事件对应两条以上通知，处置后该比例应显著下降。对比时保持统计口径一致：同样的渠道范围、同样的接收人范围、同样的时间粒度。
如果对比后仍有少量事件对应多条通知，回到 S2 的假设表逐条核对，确认是否还有未清理的重叠条目或未覆盖的重试路径。
构造测试事件验证
在受控条件下触发一次典型事件，例如创建一条测试工作项并变更其状态，或提交一次测试合并请求，观察各渠道实际收到的通知条数。预期结果是每个配置了通知的渠道各收到一条，且同一渠道内不出现重复。测试事件应使用独立的测试对象，避免干扰真实业务数据。
复发预防清单
- 统一事件去重键：在集成与投递环节约定以事件 ID 或业务唯一标识作为去重依据，接收端按该键做幂等处理。
- 规则归口管理：通知规则集中在一处维护，项目级、仓库级规则在新增前先检索是否已有覆盖同一事件的条目。
- 订阅定期清理：按季度核对应用授权、成员身份与机器人绑定清单，清理失效或重复记录。
- 变更前评审通知配置：修改通知规则、重试参数或集成授权时，走一次轻量评审，确认影响范围并留存原配置。
- 保留发送日志：确保发送日志的保留周期覆盖至少一个完整的排查窗口，便于复发时快速取证。
这几项措施的共同点是把“谁在什么条件下会收到通知”变成可查、可比对的信息。规则越集中、去重键越统一，重复通知的排查成本就越低，复发时也能更快定位到具体环节。
常见问题
同一条通知在几秒内出现两条，和间隔几分钟再出现一条，排查方向有什么不同？
几秒内出现两条，通常指向一次事件被多次投递：可能是事件源侧同一事件被推送了两次，也可能是同一事件同时命中了两条通知规则。排查时优先看事件源投递日志和规则清单。
间隔几分钟再出现，更接近投递超时后的重试或消费失败后的重放。这类情况要对照发送日志的重试记录，并检查接收端是否按事件ID做了去重。两种形态也可能叠加，找到一处原因后仍要逐段确认。
停用一条通知规则之前，需要确认哪些信息？
至少确认三项：这条规则服务的项目或仓库范围、它覆盖的事件类型、以及它当前指向的接收目标（成员、群或机器人）。如果其他业务依赖这条规则的通知，停用后会出现漏通知。
操作前导出原配置副本，停用后观察一轮实际通知是否正常。确认无影响后再删除冗余条目，保留回退路径。
接收端由外部系统承载，去重逻辑无法自行修改时怎么办？
先在发送侧减少重复来源：合并重叠规则、收敛多渠道订阅、确认重试策略是否过于激进。这些动作能降低重复投递的次数，但不解决接收端把重试当新通知展示的问题。
与接收端维护方约定去重要求：同一事件ID在有效窗口内只处理一次。在对方实现之前，可以通过缩短重试窗口或调整超时参数降低重发概率，同时记录原参数以便回退。
处置完成后观察多久、用什么指标判断已经恢复？
建议选取处置前后各一段相同长度的时间窗口，例如各三天，按事件ID统计每个事件对应的通知条数分布。处置后对应两条以上通知的事件比例应明显下降。
再构造一次测试事件，例如创建测试工作项并变更状态，确认每个配置了通知的渠道各收到一条。两项都通过，可以认为本轮处置有效；仍有少量事件对应多条通知时，回到原因假设表继续核对未清理的重叠条目或未覆盖的重试路径。
成员账号重建或群聊迁移后，旧订阅为什么会继续产生通知？
账号重建会生成新的成员身份，旧身份上的订阅关系不会自动迁移或失效；群机器人迁移后，旧群聊的绑定可能仍然保留。两者都会让同一事件被新旧两条连接各处理一次。
处置时按授权、身份、机器人绑定三份清单逐项核对，合并或停用重复记录，并确认保留的绑定指向当前在用的对象。清理建议分批执行，每批之后观察一轮通知是否正常。
