新文章发布和收到留言时，邮件提醒分别挂在哪个事件上

新文章发布和收到留言这两件事，邮件提醒挂在不同的事件组上：新文章发布属于写入类事件，触发点是内容状态转成正式文档的那一刻；收到留言属于审核类事件，触发点是留言进入内容审核队列。后台有邮件提醒这项能力，配置时按事件分组，草稿状态不该触发对外提醒。

事件分三类：写入、审核、异常

先把要提醒的事归堆，再谈发多少封。写入类是内容状态的变化：保存草稿、草稿转正式、待发布内容到点转正，都落在这一组。审核类是从站外进入站内的待办：留言先进内容审核队列，有人看过才对外可见。异常类是运维动作的结果：备份有没有跑成、部署动作有没有报错。三类事件的收件人不是同一批人，混在一组里配，很快就会有人开始忽略邮件。

发布与转正两个时点的差别

内容状态分正式文档、草稿、待发布、回收站四种，对外可见只发生在正式文档这个状态上。所以发布提醒真正该盯的是进入正式文档的时点，而不是编辑器里点保存的时点。

两个到达路径要分开看。人工把草稿转成正式，是一个时点；待发布内容按定时发布到点自动转正，是另一个时点，它在设定时间之前其实还不对外，提前发信会让收件人点开才发现什么都没有。同理，把正式文档移进回收站只是隐藏，并不是物理删除，这类中间态动作不必逐条通知。

留言类提醒为什么要接审核队列

留言不该在写入瞬间就通知所有人。合理的链路是：留言进入内容审核队列，敏感词过滤先过一遍，命中规则的做关键词替换或驳回处理，剩下的才等人审。提醒挂在进入待审队列这个时点，收件人限定在有审核职责的几个人；只有真正过审上线的留言，才值得再给内容作者发一封。

时点挂错的后果很直接：垃圾留言也会触发发信，几天之后所有人都会把这组邮件标记成忽略，真正需要处理的待审反而被埋掉。

收件人分组与降噪

分组按职责，不按通讯录：内容维护的人收发布与转正，审核的人收待审队列，负责运维的人只收异常。降噪有三条可做。同一来源在短时间内反复触发时合并成一封；邮件正文里带上标题、当前状态、涉及栏目这几项，收件人不用登录也能判断要不要处理；不需要他人知晓的动作不进入日常提醒。

全站替换、导航调整、水印设置这类偏一次性的操作，做的时候有人知道结果就行，不必每次发信。事件分组定下来之后，日常只调收件人范围和合并规则，比逐条开关更省事。

不该挂在提醒上的事件

三类动作明确排除。草稿的保存与预览，草稿只在站内协作范围内有意义，能预览不代表内容成立；回收站的移入移出，属于中间态；正文里错别字和旧链接的批量修改，那是全站替换的日常使用，操作的人自己看结果就行。

排除之后，真正需要发信的只剩三句：内容对外可见了、有人在等审核、运维动作失败了。

常见问题

问：新文章设了定时发布，提醒会在设定时间发还是提前发？ 答：按状态判。到点从待发布转成正式文档才是对外可见的时点，提醒跟着这个时点走，提前发会让收件人误判内容已经上线。

问：留言量大的站点怎么把邮件数量压下来？ 答：只对待审队列发信并按来源合并，过审上线的再单独通知作者一次，其余情况一律不发，敏感词过滤直接拦掉的那批也不必通知。

问：备份失败要不要也并进这一组提醒？ 答：要，但收件人只给负责运维的人。它属于异常类，和内容维护的收件组分开发信，双方才不会被无关邮件淹没。