再谈Notes邮件群发：链路、调优与事故排查全攻略

Notes邮件群发这个话题，隔一段时间就会有人重新翻出来。尤其现在很多老的Domino应用把通知、报表、待办提醒全部挂在邮件系统上，动不动就是几千封、上万封地发。不少同事随手用NotesDocument.Send写完就上线，等量级上来以后服务器开始卡顿、队列堆积、甚至整个路由器假死，这时候再回头排查，代价已经非常大。

这篇文章算是一个阶段性的实践整理。"再谈"是因为以前零散写过好几篇，这次干脆把链路、代码、服务器参数、方案选型、事故排查五块内容放到一起，尽量给出一份可以直接照着落地的方法。内容主要适合正在写Notes群发代理的开发者、负责Domino服务器的管理员，以及准备做企业内部通知系统方案选型的人参考。文章里的示例都以常见Notes邮件环境为准，不针对特定行业，也不涉及任何具体的单位内部材料。

先直接说结论：Notes邮件群发百分之八十的问题，不是开发人员不会写代码，而是对邮件对象的生命周期、路由器的工作方式、服务器端限制这三者的理解没有对齐。下面把每一块拆开讲清楚。

1. 先把链路看清楚：一封群发邮件到底是怎么走完的

很多开发人员把"发邮件"看作一个黑盒动作：调用Send，邮件就出去了。实际上Notes里的邮件本质上就是一个Notes文档，发信程序做得再简单，背后也牵扯到路由器、MAIL.BOX、目录解析、SMTP转换等一连串动作。只有把这条链路完整捋一遍，才知道每个环节都有哪些坑。

1.1 邮件对象和路由器的基本动作

在Notes平台里，一封邮件的本质是一个Form为Memo的Notes文档。开发人员做群发时，通常会在某个数据库里创建这样一个文档，填好SendTo、Subject、Body等字段，然后调用Doc.Send方法把它交给路由器。路由器收到这封待发邮件后，会先做收件人解析：把个人文档、群组、Internet地址全部展开成一个个实际投递地址，然后把邮件放进服务器的MAIL.BOX队列，最后根据目标地址分发给本域用户或通过SMTP发到外部域。

群发和一对一的最大区别在于，收件人解析的耗时是会累加的。你给一个群组发了一封有100人成员的邮件，路由器要把这100个成员全部展开；你给100个群组发了同一封邮件，解析成本可能比100个独立收件人还高，因为每个群组展开都需要在目录里做多次查询。这个"解析-展开"的过程恰恰是整个链路里最消耗CPU和目录服务资源的环节。

另一个容易忽略的动作是已发送副本。在客户端界面上手动发送邮件时，勾选"保存副本"后会多写一份已发送邮件到发件人的邮箱中。用API发信时同样会有这个逻辑，数量一多，发件人邮箱的体积会快速增长，随之带来的是磁盘占用、备份变慢、归档复杂等一系列问题。后面我会专门讲怎么处理。

1.2 三个真正的瓶颈点

把整条群发链路拆开看，真正会堵住的瓶颈基本集中在三处：

我见过不少群发事故，表面上看是服务器性能问题，实际根因往往出在第一个瓶颈：一个收件人列表里混了十几个大型群组，路由器在展开群组时反复查询目录，最终把路由进程拖到无响应。更麻烦的是，这种问题在几百封的小规模测试时完全看不出来，只有等全量发送才暴露，一旦暴露，可能已经造成了几个小时的服务中断。

第二个瓶颈同样典型。曾有一次客户反馈邮件全部堆积在服务器上，检查MAIL.BOX发现里面躺着两万多封待发邮件，路由器任务一直处于高负荷状态。原因很简单，发送程序把两万多个收件人一次性放进了一个数组，然后生成了一封超大收件人列表的邮件，路由器按单条消息的规则尝试处理，反复拆分、反复重试，队列就一直涨。后面在服务器参数和程序设计两层都做了限制，才彻底解决。

第三个瓶颈发生在混合环境里。Notes内部用户之间传输走的是Notes协议，外部用户走SMTP。如果你的群发对象同时包含了Notes用户和Internet邮箱地址，邮件在出口处要做一次格式转换，正文的富文本、附件、编码都有可能在这个环节出问题。所谓"发了但对方收到是乱码"、"空白邮件"、"附件打不开"，多数都是在这里埋下的雷。

2. 写群发代码前，先把这四个坑绕开

代码层面看起来很简单：一个Send方法就够了。但实际写过几千封以上群发的朋友应该都有印象，细节全在收件人参数、正文构造、发送副本和处理节奏上。下面这几个坑，基本是每次讨论群发必被问到的。

2.1 Send方法参数别用错

先看一个标准发送代码片段，这是我在生产环境里用过的写法，可以直接作为参考。

Dim session As New NotesSession Dim db As NotesDatabase Set db = session.CurrentDatabase Dim doc As NotesDocument Set doc = db.CreateDocument Call doc.ReplaceItemValue("Form", "Memo") Call doc.ReplaceItemValue("Subject", "系统通知：第三季度账单已生成") Call doc.ReplaceItemValue("SendTo", recipientArray) Dim rt As NotesRichTextItem Set rt = doc.CreateRichTextItem("Body") Call rt.AppendText("您好，您在本季度的账单数据已经生成，请登录内部系统查看。") Call rt.AddNewLine(2) Call rt.AppendText("如有疑问，请联系IT服务台。") Call doc.Send(False, recipientArray)

这里最关键的两个地方，一是CreateRichTextItem构造正文，二是Send(False, recipientArray)的参数。Send方法的第一个参数表示是否把当前数据库中的附件一起带过去，群发场景下大多设置为False，意思是不额外附加数据库中的文档，只发送当前内存里的内容。第二个参数是收件人数组，这也是群发最常用的形式。

新手容易犯的错误是：把部分收件人放进CopyTo或BlindCopyTo。这样不是不行，但收件人会看到自己收到的是抄送，而且在路由器处理时，抄送和密送会走不同的字段逻辑。如果你并不需要体现"抄送"这个语义，就老老实实全部放到SendTo里。否则后续做投递状态跟踪、收件人统计时会发现数据对不上，排查起来很费劲。

另外要特别注意，SendTo字段如果已经存在旧值，Send方法并不会自动帮你清掉。我曾经见过一个循环发送的代理，第一轮往SendTo写入了100个收件人，第二轮又追加了100个，结果第三轮发信时把前面两轮的收件人也一起带上了。正确做法是在每轮循环创建新文档，或者发送前调用doc.RemoveItem("SendTo")清理干净。

2.2 已发送副本的失控问题

用API发送邮件后，系统默认会在发件人的邮件库里生成一封"已发送"副本。手动发一两封没感觉，但如果你的代理是循环群发，每封邮件都存一份副本，几千封下来就是几千个文档。这些文档占用的磁盘空间比你想的要大得多，尤其当邮件带有附件时，一个附件会被反复复制很多份。

我在某次生产事故里遇到的情况是：一个每周跑一次的通知代理，半年没有清理，发件人邮箱的数据库文件从2GB涨到了30GB，直接影响了备份时间和服务器的整体响应。后来采取的方案有三个，可以根据你的实际情况组合使用。

第一，使用一个专用的系统发件人邮箱。群发程序统一从一个"通知中心"邮箱发信，这样即使已发送副本积累了很多，也不会干扰真实员工的个人邮箱，归档和清理都更可控。第二，如果只能在某个人自己的邮箱里跑代理，那就定期清理已发送视图。第三，调低保存完整性要求，不使用doc.SaveMessageOnSend这类额外记录机制，保持最简的发送流程。这些操作虽然朴素，但能把运维成本降一大截。

2.3 大批量收件人的分批策略

几千封以内的群发，用一个数组把所有收件人塞进去，直接Send通常没有问题。但如果超过一万封，我强烈建议分批发送。一方面是因为路由器对单条消息的收件人数量有限制，另一方面是如果你的列表里有群组，单次展开的规模很快会超出服务器的承受能力。

我的经验是把每批控制在800到1000个收件人，批与批之间做一个小暂停。这个数值不是拍脑袋定的，它兼顾了解析耗时和队列积压量。假设一封邮件平均解析耗时0.05秒，1000个收件人就是50秒的解析窗口，这个窗口不会让路由器进程长时间无响应。如果你一口吃下2万个收件人，解析窗口会拉长到十几分钟，期间任何其他正常邮件都会被阻塞。

暂停的方式很简单，循环里加一个时间判断或者用Sleep类似的机制。在Notes代理里通常用Session的时间函数或者直接调用外部API，也可以干脆把任务拆成多个代理，每个代理只处理一批，用调度时间错开。后者在实际运维中更可靠，因为服务器崩溃时至少只丢一批。

2.4 正文、附件和编码的三重保障

正文必须是富文本项，不要用ReplaceItemValue直接塞纯文本。这句话我在多个场合重复过很多遍。用纯文本字段保存正文，客户端界面显示时很容易变成空白，因为Notes的MIME转发机制与富文本项的处理方式不一样。正确做法就是上面代码里的CreateRichTextItem("Body")。

附件方面，如果你的群发对象是几千人，并且附件很大，我提醒你算一笔账：1万封邮件，每封带5MB的附件，就是50GB的出站数据。这还只是应用层的数据量，经过邮件传输协议、协议头、MIME编码之后实际更大。对于这类场景，我建议不要在邮件里放附件，而是把附件放到企业内部文件服务器或网盘上，在邮件正文里给出下载链接。如果真的必须发附件，先把服务器端的SMTP消息大小限制确认好，避免发送超限后邮件被路由器反复重试。

编码问题跟正文一样隐蔽。Notes本身处理中文没有问题，但如果你群发的对象里有大量Internet邮箱，邮件出口时要经过SMTP编码转换。过去很多乱码问题出在主题编码上，服务器端没有启用合理的标题编码方式，中文标题经过SMTP后变成了乱码。新版Domino服务器对UTF-8的支持已经改善，但老环境仍然需要检查国际MIME设置。这类问题最烦人的地方在于：内部用户互相收发完全正常，只有发向外部的邮件出问题。

3. 服务器端配置调优记录

写代码的人往往只盯程序逻辑，管理员则要盯服务器参数。群发功能要想在质量上站得住脚，两端缺一不可。下面这些配置我在不同版本的环境里都验证过，属于通用性比较强的内容，可以按需取用。

3.1 服务器文档里先改这三项

第一项是"每个消息的最大收件人数"。这个设置位于服务器文档的Router/SMTP限制与控件区域，老版本里可能在传递控制或者限制页面下，不同版本菜单位置略有差异，但关键字段是同一个：单个消息最多允许多少个收件人。系统默认值通常在2000左右，如果你们有大批量群发需求，可以按业务规划适当调高，但我不建议无脑调到很大。这个参数本质上是路由器的兜底保护，防止某个意外应用把几万收件人塞进一条消息。

第二项是SMTP消息大小限制。在服务器文档的SMTP设置里，可以分别限制入站和出站消息的最大大小。如果群发对象里有外部邮箱，这个值一定要跟业务方确认清楚。设得太小，正常业务附件发不出去；设得太大，一个5MB附件乘以一万封邮件，足以让网络链路出口带宽被打满。

第三项是路由器并发任务数。老版本的Domino在notes.ini中可以通过几个参数控制路由器的并发投递和传输任务数。默认值在大多数情况下是够用的，只有在群发场景下才需要调整。修改时要记住一个原则：并发数调大确实能提升发送速度，但代价是更多的CPU和磁盘IO，服务器资源不够时反而会拖垮整个Domino服务。

3.2 关键参数与推荐值

我整理了一个简表，方便管理员对照检查。

这里要特别说明，任何参数都不要在没有监控的情况下一次性调到最大。我见过有人把并发任务数从默认值翻了三倍，结果服务器CPU立刻冲到98%，正常邮件也跟着卡住。正确的调优方法是：改一档，观察一段时间，确认路由器队列在下降、CPU在可接受范围，再继续调。宁肯发送慢一点，也不能让核心邮件系统不稳定。

3.3 常用监控命令

群发期间一定要学会看队列。以前我在处理一次大面积邮件堆积时，就是在控制台敲了几条命令，才快速定位到问题出在路由器阻塞而不是网络故障。下面是几个最常用的命令，在Domino服务器的控制台界面直接输入即可。

show tasks show stat mail show stat router dspt mail.box

show tasks可以查看路由器任务是否还活着；show stat mail和show stat router给出的是邮件统计信息，比如当前队列里有多少条待发邮件；dspt mail.box则直接列出邮件队列数据库里的文档数量。如果发现队列在持续增长，基本可以判断是路由器投递速度赶不上进入速度。

有时路由器进程会假死，症状是控制台响应慢、队列一直不动。遇到这种情况，可以先尝试重启路由器：

tell router quit load router

这两条命令切忌在业务高峰期随意执行，因为重启路由器会让正在处理的邮件重新排队，可能引发短时间的投递延迟。稳妥的做法是先观察队列和日志，确认是路由器进程本身出了问题再重启。

3.4 防止群发风暴的三道闸

说实话，服务器端的参数调优只是最后的防线，真正让群发功能稳定的关键在于应用层错峰。我会建议在三个层面同时做限制。

应用发起时，由发送程序自身控制节奏，分批发送，批间暂停，避免一次性灌爆队列。服务器侧，通过每个消息最大收件人数限制，防止单条消息异常膨胀。基础设施侧，给邮件数据库设置合理的配额，尤其是MAIL.BOX，避免磁盘被异常数据塞满。三道闸都做好，即使某次发送内容出现异常，也不会拖垮整台服务器。

4. 四种群发方案的适用性对比

代码和服务器参数都聊完了，接下来要解决的是方案选型问题。很多项目一上来就写最基础的循环发送，等到需求量变大、运维要求变高，才发现结构不对。下面拿四种常见方案逐一点评，你根据自己业务规模挑选即可。

4.1 方案一：单文档多收件人直接Send

这就是文章开头那段代码的完整场景。适合临时性、一次性的通知，发送内容完全相同，收件人数量在几百到几千之间。优点是开发成本极低，一张Memo加一个数组就能跑。

缺点也很明显：收件人列表越大，路由器单条消息的解析时间越长；一旦超过服务器"每个消息最大收件人数"，整封邮件都会发送失败，而且失败难以定位。所以这个方案适合做"轻量级群发"，不适合作为核心业务的消息通道。

4.2 方案二：逐封循环发送

对每个收件人单独创建一个邮件文档、单独调用一次Send，适合账单、报表、个性化通知这类内容需要按收件人变化的场景。代码逻辑也简单，把上面的代码放到一个For循环里就行。

For i = 0 To Ubound(recipientArray) Set doc = db.CreateDocument Call doc.ReplaceItemValue("Form", "Memo") Call doc.ReplaceItemValue("Subject", "个人账单通知") Call doc.ReplaceItemValue("SendTo", recipientArray(i)) Set rt = doc.CreateRichTextItem("Body") Call rt.AppendText("您好，以下是为您个人生成的账单……") Call doc.Send(False, recipientArray(i)) Set doc = Nothing Next

这个方案的优点是灵活，缺点是在大量收件人面前性能偏低。每循环一次就要创建文档、构造正文、调用一次发送，即使没有额外保存副本，服务器开销也比方案一大得多。实际使用时建议控制在几百到几千封的量级，超过再往上走就要考虑拆分成多个调度任务。

4.3 方案三：群组转发

把收件人维护在一个群组文档的成员列表里，发送时SendTo只填群组名字，由路由器自动展开群组成员后投递。它的好处是日常维护成本低，今天加了新员工，只要更新群组成员，下次群发自动带上新人。

但群组方式有两个容易被忽略的坑。第一，群组展开是运行时的目录操作，群组成员越多，解析耗时越长。第二，如果同一个收件人同时出现在两个群组里，且你把这几个群组都填进了SendTo，路由器会各自展开、各自投递，结果就是同一封邮件收两次。所以在真实运维中，群组方案适合成员相对稳定、数量不太大的机构性通知，不适合临时拼凑的大规模名单。

4.4 方案四：任务表加定时代理

这个方案是我在正经企业环境里最推荐的一种。它的做法是单独建一张"待发送任务"表单，每条记录保存收件人、主题、正文、发送状态、计划发送时间这些字段。后台用定时代理每隔几分钟扫一次任务表，每次只处理未发送且在计划时间内的任务，发送完成后把状态更新为"已发送"。

这么做的好处是发送节奏完全可控，任务表里能看到每封邮件的处理状态，发送失败可以重试，还能按业务字段做分类统计。代码量比前面的方案多出百分之二十左右，但换来的是长期可维护性。对于用户账单、审批待办、定期报表这类核心群发场景，我认为这是最靠谱的落地方案。

4.5 方案快速对比

选型没有绝对的好坏，关键是匹配场景。如果只是临时喊一嗓子，不用为了一次通知搞复杂的任务表；如果是每周都要跑的核心业务，也别图省事继续用一次性发送。

5. 几个真实事故复盘与排查手记

最后这部分是我自己踩过的坑，也是每次聊"再谈Notes邮件群发问题"时大家最爱听的内容。事故都不复杂，但很典型，你可以把它当成一份排查速查表来用。

5.1 事故一：一次性群发把路由器拖死

现象：某天下午开始，单位内部大量邮件延迟，控制台show stat router显示队列持续增长，路由器进程CPU接近100%，部分邮件在队列里卡了数小时。

复盘：发送程序的开发者把两万多个收件人一次性装进数组，生成了一个大收件人列表的消息。路由器在解析这条消息时，需要把名单里的每个地址都展开、校验、生成投递任务，整个进程被拖到近乎无响应。期间其他正常的业务邮件也排在同一队列，跟着遭殃。

处理：先把发起方程序停掉，清理队列里堆积的那封超大消息，让路由器恢复正常；然后修改应用，按1000人一批的方式分批发送，批次之间错峰。从那以后，所有群发程序上线前必须经过小规模到中规模再到全量的阶梯测试。

5.2 事故二：发件人邮箱的已发送副本爆炸

现象：磁盘空间连续数周缓慢下降，某天早晨监控报警，查一下发现是一个内部通知邮箱的数据库文件异常巨大，已发送视图里有几十万个文档。

复盘：这个通知邮箱是群发代理的发件人，代理每轮循环都往该邮箱保存了一封已发送副本，日积月累把数据库撑爆。更麻烦的是，数据库做备份和压缩时耗时越来越长，已经影响到了其他应用。

处理：把已发送视图里超过90天的旧文档批量删除，给该邮箱设置数据库配额，同时修改发送代理，让临时生成的邮件文档只用于发送，不长期留存副本。此后我要求所有群发代理上线时，必须明确已发送副本的保留策略。

5.3 事故三：收到系统通知但正文是空白

现象：互联网邮箱用户收到系统通知邮件，主题正常，点开后正文区域一片空白。

复盘：开发人员在构造邮件时用ReplaceItemValue("Body", text)塞了一段文本。这个字段虽然叫Body，但它是文本类型而非富文本类型。邮件在出站时转成SMTP标准格式，文本型Body没能正确映射到MIME正文，客户端就显示了空白。

处理：把所有群发代理中的正文构造统一改成CreateRichTextItem，并重新发送一遍测试邮件验证。从那以后，我在代码审查中加了一条规则：正文必须用富文本项构造。

5.4 事故四：同一个人收到两封相同的通知

现象：部分收件人反馈同一个通知收到两次，时间非常接近。

复盘：排查发现这些用户同时存在于两个群组里，而发送程序把这两个群组都写进了SendTo。路由器展开群组时分别生成了两条投递任务，于是同一用户被投递了两次。

处理：在发送前对收件人列表做去重，把群组展开后的实际收件人合并后重新生成SendTo。如果是用群组维度发送，则检查群组文档的成员构成，避免一个邮箱地址重复出现在多个群组。

5.5 排查速查表

以上排查顺序基本能覆盖九成以上的群发故障。真遇到不常见的问题，别急着改程序，先把邮箱、队列、路由器日志这三样基础数据拉出来，大部分线索都会浮出水面。

最后分享一个我坚持了很多年的个人习惯：凡是超过一千封的正式群发，我默认使用任务表加定时代理的方案，宁可代码多写一点，也要给每封邮件留下可查询的状态记录。再有就是监控指标务必提前留好，MAIL.BOX大小、路由器队列长度、发送成功率这三个指标，能在关键时刻帮你省下好几个小时的排查时间。Notes邮件群发并没有多高深的技术含量，把底层机制摸透、把参数调对、把方案选合适，基本就不会再被这类问题折腾了。