在企业微信外部群运营中，群发经常被理解成一个简单动作：设定发送时间，到点调用接口，把消息发到目标客户群。
但在实际业务中，一次群发往往需要经历内容编辑、目标筛选、人员确认、任务执行、结果查询、失败处理和数据统计等多个阶段。如果只使用一个定时脚本，很难准确判断任务当前处于什么状态，也无法处理部分成功、重复执行和人员未操作等情况。
因此，群发任务更适合采用状态机设计。
一、创建群发任务不等于消息已经送达
企业微信客户群群发与普通系统通知并不完全相同。
在官方客户联系群发体系中，创建企业群发任务后，消息并不一定立即直接到达客户或客户群，相关成员可能还需要在客户端完成确认或执行。企业微信也提供了群发任务列表和成员执行结果查询接口。
这意味着业务系统至少需要区分三个概念：
群发内容已经创建；
成员已经执行发送；
目标客户群实际发送成功或未成功。
如果系统只记录"接口返回成功"，很容易把任务创建成功误认为最终发送成功。
二、群发任务应有明确状态
一个较完整的群发任务，可以设置以下状态：
草稿状态
运营人员正在编辑消息内容、附件和目标客户群，任务尚未进入执行流程。
待审核状态
适用于需要内容审核的企业。审核人员可以检查文字、图片、链接、适用范围和发送时间。
待执行状态
任务已经通过审核，但还没有到发送时间，或者正在等待相关成员执行。
执行中状态
群发已经开始，部分成员或客户群已经完成发送，部分仍在处理中。
部分完成状态
部分目标发送成功，但仍有成员未执行、客户群失效或其他异常。
已完成状态
所有可执行目标均已完成，或者任务已经满足企业定义的完成条件。
已取消状态
运营人员主动停止任务，尚未执行的部分不再继续。
异常状态
由于接口错误、权限变化、账号离线、目标群不存在或系统故障，需要人工检查。
状态越清晰，运营人员越容易知道任务现在发生了什么。
三、目标群应该在什么时间确定
群发任务还有一个重要问题：目标群名单是创建时确定，还是发送时动态查询？
两种方式各有特点。
创建时生成快照，可以保证审核时看到的对象和实际执行对象基本一致。但如果某个群在发送前已经结束，仍然可能被包含在任务中。
发送时动态查询，可以自动排除已归档或不符合条件的群，但可能导致审核范围与最终发送范围不一致。
更稳妥的设计是同时保留两份数据：
创建任务时保存原始筛选条件；
审核通过时生成目标群快照；
正式执行前再次校验群状态；
对被排除的群记录具体原因。
这样既能保证任务可追溯，也能避免向已经结束或状态异常的客户群发送内容。
四、群发任务必须设计幂等机制
定时任务可能因为服务器重启、网络超时或任务队列重试而被执行多次。如果没有幂等控制，同一批客户群可能收到重复内容。
可以为每次群发生成唯一任务编号，并为每个目标群生成独立执行编号。
例如：
群发任务编号 + 群编号 + 内容版本号
在真正调用发送接口前，先检查该执行编号是否已经成功处理。如果已经完成，就不再重复发送。
内容修改后，也不能直接覆盖原任务。比较稳妥的方式是生成新的内容版本，保留旧版本的审核和执行记录。
五、部分成功比完全失败更常见
大规模群发很少只有"全部成功"和"全部失败"两种结果。
常见情况包括：
一部分运营成员已经执行，另一部分尚未执行；
某些客户群已经结束；
群主不在应用可见范围；
某些账号状态异常；
个别附件上传失败；
发送过程中任务被人工停止；
部分目标因为规则限制无法继续触达。
因此，系统不能在出现一个错误后就把整项任务标记为失败。
更合理的方式，是分别记录每个成员、每个群和每个发送批次的执行结果。主任务状态由这些明细汇总而来。
如果有 100 个目标群，其中 95 个完成，3 个不符合发送条件，2 个需要人工处理，主任务可以标记为"部分完成"，并明确展示剩余问题。
六、失败重试不能无限进行
并不是所有失败都适合自动重试。
网络超时、临时服务不可用，可以按照退避策略进行有限次数重试。目标群不存在、权限不足、成员离职或内容被停止，则不应继续自动重试。
可以把错误划分为三类：
临时错误：自动重试；
业务错误：停止执行并记录原因；
未知错误：进入人工处理队列。
这样可以避免系统对明确无法完成的任务反复调用接口。
七、群发记录也是审计记录
一次群发任务应当保留完整记录，包括：
谁创建了任务；
谁修改了内容；
谁完成了审核；
目标群如何筛选；
使用了哪个内容版本；
什么时候开始执行；
哪些成员已经处理；
哪些群发送失败；
任务是否被停止；
最终完成情况。
这些信息不仅用于统计，也便于在内容错误或客户投诉时还原过程。
八、总结
企业微信群发不是一次简单的接口调用，而是一条包含内容、对象、人员和结果的执行链路。
使用状态机管理草稿、审核、执行、完成和异常，可以让群发过程更可控。再配合目标快照、幂等控制、结果明细、有限重试和审计记录，才能避免重复发送、任务失控和结果不可追踪。