“我们不是没发消息，是发出去就像石沉大海——不知道发给了谁、看没看、失败了没有，最后全靠秘书挨个打电话确认。”这正是诸多企业面临的真实困境。

JNPF 7.0重构了“消息中心”板块，把公告、消息模板、发送配置、接收配置、消息安全、消息记录、消息审计全部串联到了一条链路上。接下来就带着大家把能落地的场景和踩过的坑一次性讲清楚。

01 痛点：消息发出去，却像断了线

在讲怎么配之前，先把痛点摆出来，大家可以对照一下自己公司中了几条。

- 消息和人对不上。流程审批推给张三、系统告警推给运维、全员公告推给所有人——混在同一个入口里，谁也说不清这条消息到底该谁看。

- 读没读没人知道。财务通知“明天中午前交报销”，到点了还有一半人没交，你去问，对方说“没收到”。没有回执，这事永远扯不清。

- 发送失败了不知道。短信通道临时挂了、邮件地址退信了，消息发出去平台显示“已提交”，但用户根本没收到，等出了事才发现。

- 对外推送没把关。市场部通过公众号、短信给客户群发活动文案，里面混了一个敏感词，发出去才被法务发现，已经撤不回来。

- 没有数据可看。老板问一句“上个月我们总共发了多少条通知？触达率多少？哪个渠道最靠谱？”，答不上来。

这五个问题看起来散，其实根子是同一个：消息从“发送”到“被看到”之间，缺了一条可管、可查、可审计的链路。JNPF快速开发平台的消息中心，补的正是这一段，把所有链路统一管控，串成一条完整的闭环。

02 先分类：给每条消息上“户口”

业务类别：消息配置的地基

配消息中心的第一件事，不是急着选渠道，而是先把消息分类。JNPF 7.0在这里做了一个比较关键的改动：原来笼统的“消息来源”，改成了业务类别。

一级业务类别系统给了五个：应用、流程、系统、公告、其他。下面还可以继续拆二级、三级。别小看这一层分类，它直接决定了后面三件事：模板怎么配、渠道怎么选、审计怎么统计。

集团多业务怎么分？

以一家多业务线的集团为例，实际配置的时候可以这么拆：

- 流程类：审批待办、流程驳回、节点催办——这些跟着流程引擎走，推给具体经办人。

- 公告类：公司级通知、部门通告、制度发布——这些是全员或指定范围的。JNPF 7.0把公告细分成了“通知”和“通告”两种类型，轻量事项用通知，正式制度类用通告，一眼就能区分。

- 系统类：登录异常、数据备份完成、接口告警——这些是给运维和管理员看的。

接收渠道：灵活选择搭配

分完类之后，到“接收配置”里按业务类别勾选推送渠道。JNPF支持的渠道有：站内信、邮件、短信、微信公众号、企业微信、钉钉、飞书。

这里有个很实用的细节：管理员可以对已经勾选的渠道设置“锁定”。锁定之后普通用户自己在个人设置里就改不了，避免出现“财务通知我把它关了”这种事。没有锁定的渠道，员工自己可以按需开启或关闭。每类消息还有一个启用开关，临时想停掉某类推送，一键关掉就行，不用删配置。

实际落地建议：流程类消息默认走站内信+企微/钉钉，保证经办人能即时收到；公告类走站内信+邮件，重要公告再叠加短信；系统告警类直接推运维的企微群和短信。别什么消息都开短信，成本根本就扛不住。

发送方式：同步还是异步，别选错

“发送配置”里新增了一个发送方式选项，该功能具体用法如下：

- 同步发送：发一条，等服务端返回成功再发下一条。适合量小、要求顺序的场景，比如审批节点逐个通知。

- 异步发送：发出去不等返回，接着发下一条。适合批量推送，比如全员公告、营销群发，吞吐量高。

这边建议大家：流程类、告警类用同步，保证顺序和即时确认；公告群发、对外推送用异步，别让发送动作把主业务卡住。

03 再发送：回执、记录、失败重发

分类和渠道搞定之后，接下来解决最痛的那个问题：这条消息，对方到底看没看？

已读回执：两种模式按场景选

JNPF 7.0在公告管理里加了已读回执开关，支持两种模式：

- 阅读自动回执：用户打开公告详情页，系统自动上报已读。适合一般通知，不打扰用户。

- 手动确认回执：用户看完必须主动点“确认回执”按钮，发送方才算收到回执。适合制度签收、安全通知、培训确认这类需要“当事人明确认领”的场景。

发出去的公告，在列表里点“回执详情”，能直接看到“已回执”人员名单。谁看了、谁没看、谁确认了，一目了然。再也不用挨个问“收到请回复”了。

另外一个顺手的功能是定时发送。今晚要发的公告，可以设到明早9点自动发；没到时间之前状态是“待发送”，想提前发，点一下“即时发送”就行。

消息记录：每条消息的全生命周期都在这

“消息记录”是从原来的系统监控里挪过来并改名的，但比原来好用很多。它记录了所有消息的发送详情，几个关键字段：

- 业务类别：这条消息属于流程/公告/系统哪一类，直接归类。

- 发送方式：同步还是异步，和发送配置对应得上。

- 状态：正在发送、发送成功、发送失败，三态清楚。

- 阅读情况：站内信类的消息，点详情能看到谁读了、什么时候读的。

- 发送记录：每一次尝试的时间、结果、失败原因（比如“手机号码格式错误”“邮箱退信”）都写在里面。

这一点对排查问题特别有用。以前用户反馈“没收到”，你只能干瞪眼；现在直接在消息记录里搜这条消息，看是发送失败还是压根没触发，原因写得明明白白。

失败重发：避免重复操作

发送失败的消息，配合重发机制处理就行——不用把公告或模板重新写一遍，在记录里针对失败的那批接收人直接重发，系统会带着原模板和原参数再走一次发送流程。通道临时故障恢复之后，这一步能省掉大量人工补发的活。

04 安全：对外推送先过“安检”

前面说的都是对内消息，真正容易出风险的是对外推送——通过短信、邮件、微信公众号发给客户的那批。

JNPF 7.0新增了“消息安全”模块，做的就是敏感词过滤。配置逻辑很直接：新建一条规则，填敏感词和对应的替代显示。系统在发送前自动检测，命中的词要么替换成你指定的内容，要么直接过滤掉（替代显示留空就是过滤）。

几个实际配置时要注意的点：

- 每个敏感词只能关联一种替换方案，系统会判重，避免同词多规则打架。

- 敏感词库可以按合规要求持续补充，比如金融行业的承诺收益类词汇、医疗行业的疗效保证类词汇，提前录进去。

- 对外渠道（短信、邮件、公众号）是过滤重点，对内流程消息一般不用开。

这样市场部运营即使在消息模板里手抖写了不该写的词，发出去之前系统也会自动兜一道。合规这根弦，从“人盯”变成“系统盯”。

05 看审计：可视化面板一览无余

前面所有配置跑顺之后，最后落到管理视角：这些消息到底发得怎么样？

“消息审计”就是给管理者看的看板。它把消息日志做了统计分析，核心指标包括：

- 状态分布：已发送、发送失败、正在发送各多少条，一眼看到失败量有没有异常波动。

- 公告统计：公告类消息单独按状态计数，方便评估全员通知的覆盖情况。

- 消息触达率：成功发送数 ÷ 发送总数。这个数字是管理者最关心的，也是以前最拿不出来的。

- 渠道消息数：站内信、邮件、短信、企微、钉钉、飞书各发了多少，哪个渠道是主力、哪个渠道在空转，数据说话。

- 时间范围：默认看过去7天，可以按需要拉长，做月度复盘。

这个看板实际用起来，有两个比较直接的价值：一是异常监控，某天失败率突然拉高，大概率是通道或模板出问题，能第一时间发现；二是渠道决策，比如发现短信渠道一个月发了几千条但触达率并不高，下次重要通知就优先走企微，把短信预算省下来。

---

总的来说，JNPF快速开发平台的消息中心，本质上不是给你多了一个发消息的入口，而是把企业里原来散落在各处的消息动作——公告、模板、推送、回执、记录、审计——收归到一条可追溯的链路上。对内，流程和公告不再“发了白发”；对外，敏感内容有了兜底；对上，触达率和渠道效果有数据可看。

如果你也在JNPF上搭应用，建议把消息中心作为一个独立模块先配好，再让各个业务应用去调用。前期花半天时间把业务类别和渠道规则定下来，后面省掉的是无数次“到底谁没收到”的人工确认。