留言、订单和发布提醒都走邮件，邮件提醒规则该配在哪一层

留言、订单和发布提醒都走邮件，邮件提醒规则该配在哪一层？按触发方来分层：发信通道和总开关配在系统设置层，留言与订单的收件人规则配在各自业务模块层，内容发布的提醒配在编辑协作层。把规则配在产生事件的那个模块上，通知才不会全部涌进同一个邮箱，也才能事后说清某封邮件是谁触发的。

三类通知的对象本来就不一样

分层的判断标准是「谁需要立刻知道」。运行状态类出问题影响整站，收件范围要小；业务动作类每天都有，收件人要按岗位分而不是按人堆；编辑协作类和发布节奏绑定，只在内容真正进入流程时才该发。

系统设置层只放通道和总开关

AnQiCMS 的邮件提醒能力在系统层面负责两件事：发信通道是否可用、通知功能是否开启。这一层不决定「谁的留言发给谁」，它只保证邮件能发出去。把收件人规则写在这一层是常见的错配，结果是所有事件都发给管理员，重要的运行告警反而被留言邮件淹没。

业务模块层按模块各管一段

留言通知挂在留言模块上。后台的留言列表把新留言集中处理，配合邮件提醒做到达通知，收件人应该是负责回复的人，而不是全站管理员。v3.6.5 起后台还增加了邮件订阅能力，订阅类邮件与留言提醒属于不同链路，收件人名单和退订处理也不要混用。

订单通知挂在订单模块上。AnQiCMS 支持微信公众号对接、订单管理、财务管理与分销管理，订单事件的状态变化多，规则要按状态挑触发点：待付款、已成交、退款分别决定要不要发、发给谁。把整条订单流的通知都打开，一天几十封重复邮件之后，收件人就会开始忽略它们。

接口调用时通知由谁触发

用 API 调用批量写入内容或读取数据时，容易忽略通知也在被触发。AnQiCMS 提供文档内容导入接口，接口文档里能看到调用高频能力覆盖文档列表与详情、分类与标签、上传图片、留言与评论、友情链接、系统设置与联系方式。批量导入若直接落成正式文档，发布类提醒就会成批产生。稳妥做法是批量导入先落草稿，把提醒留到人工确认之后再发。

常见问题

同一个事件能不能发多个收件人？ 能，但收件人名单要挂在业务模块层维护，避免在系统层写死；换岗位时只改一处。

通知太多想关掉一部分怎么办？ 从触发点关而不是从通道关：先关掉低价值的状态变化提醒，保留运行告警与需要回复的留言，不要直接停掉发信通道。

发布提醒怎么和定时发布配合？ 定时发布安排的是内容到点上线，提醒要发在「已上线」或「上线失败」这两个节点上，而不是在设定计划时就发。