消息与通知

本文档面向购买 VortMall 电商系统的平台运营方，说明消息模块（站内信、消息模板、即时通讯 IM）、订单类通知、邮件模板及跨境版模板翻译等典型业务流程。消息模块负责收件箱、模板管理与客服会话；IM 基于 EMQX/MQTT 实现实时客服聊天；消息模板支持 {order_sn}、{total_amount} 等变量占位符；跨境版支持消息模板多语言翻译；订单通知覆盖新单、支付、发货、收货、退款等；交易类邮件通过邮件模板发送。

1. 订单消息通知流程

系统在订单生命周期的关键节点自动触发消息通知，覆盖下单成功、支付成功、发货、确认收货、退款等场景，并通过站内信、短信、App 推送等渠道触达买家与商家，保证双方及时获知订单状态。

参与角色： 买家、商家/店铺、订单与支付子系统、消息中心、通知渠道（站内信/短信/推送等）。

flowchart TD
    orderEvent[订单状态变更事件]
    ruleMatch[匹配通知规则与模板]
    channelSelect[选择通知渠道]
    sendUser[向用户侧发送]
    sendMerchant[向商家侧发送]
    deliveryResult[记录投递结果]
    orderEvent --> ruleMatch
    ruleMatch --> channelSelect
    channelSelect --> sendUser
    channelSelect --> sendMerchant
    sendUser --> deliveryResult
    sendMerchant --> deliveryResult

步骤说明：

订单子系统在状态变更时产生事件（如下单、已支付、已发货、已收货、退款完成等）。
消息服务根据事件类型与业务规则匹配对应的消息模板与变量（如订单号、金额、物流单号）。
按配置为买家与商家分别确定需触达的渠道（站内信必选或可叠加短信、推送等）。
组装个性化内容后，向用户侧渠道投递通知。
若业务需要，同步或异步向商家侧投递通知。
记录发送结果与失败原因，便于对账与补发。

说明与规则：

同一订单节点可能对用户与商家使用不同模板或渠道组合，以配置为准。
变量须与订单事实一致，避免在支付未确认前发送「支付成功」类通知。
失败投递应支持重试或告警，避免关键节点无感知。

2. 站内信发送与管理流程

平台管理员在后台编写系统站内信，选择全体用户或指定用户范围后发送；用户在商城消息中心查看列表与详情，并可标记已读，实现运营公告与定向通知的统一管理。

参与角色： 平台管理员、站内信服务、目标用户。

flowchart TD
    compose[管理员编写站内信]
    chooseScope[选择目标范围]
    submitSend[提交发送任务]
    persistStore[持久化消息与投递任务]
    userInbox[用户消息中心展示]
    markRead[用户标记已读]
    compose --> chooseScope
    chooseScope --> submitSend
    submitSend --> persistStore
    persistStore --> userInbox
    userInbox --> markRead

步骤说明：

管理员在后台编辑标题、正文及生效策略（如立即发送或定时发送）。
选择目标：全部用户、按标签/等级筛选，或导入指定用户列表。
提交后系统校验权限与内容规范，生成发送任务。
服务将消息写入各目标用户的收件箱（或分片队列异步落库）。
用户登录后在消息中心看到未读列表，点击查看详情。
用户可单条或批量标记已读，已读状态回写服务端。

说明与规则：

「全部用户」类广播需评估性能，宜采用异步批量写入与限流。
敏感内容应走审核策略（若平台已启用），未通过不得发送。

3. 消息模板管理流程

运营人员创建消息模板并设置类型（订单、营销、系统等），在正文中使用 {变量} 占位符；模板可启用或禁用，业务事件触发时由系统自动匹配已启用模板并填充变量后下发。

参与角色： 平台运营/管理员、消息模板服务、触发业务的各子系统。

flowchart TD
    createTpl[创建或编辑模板]
    setType[设置模板类型与编码]
    editContent[编写内容含占位符]
    toggleState[启用或禁用模板]
    eventFire[业务事件触发]
    matchTpl[匹配启用模板]
    fillVars[填充变量并渲染]
    createTpl --> setType
    setType --> editContent
    editContent --> toggleState
    eventFire --> matchTpl
    matchTpl --> fillVars

步骤说明：

在模板管理中新建模板，填写名称、唯一编码及适用渠道说明。
选择模板类型：如订单类、营销类、系统类，便于检索与权限控制。
编写标题与正文，插入平台支持的占位符，例如 {order_sn}、{total_amount}。
保存后默认可设为禁用，确认无误后启用；禁用模板不参与自动匹配。
当订单、支付等事件发生时，消息服务按事件类型与模板编码查找启用模板。
从业务上下文读取变量值，替换占位符后生成最终文案并进入发送流程。

说明与规则：

占位符名称需与接口约定一致，缺失变量时应记录日志并可用兜底文案或阻断发送（依产品策略）。
同一事件若存在多个候选模板，应有优先级或唯一编码规则避免歧义。

4. 在线客服 IM 流程

消费者在商品或订单页发起咨询，系统将会话分配给在线客服；客户端与 EMQX 建立 MQTT 连接后进行实时收发，客服处理问题后结束会话，会话记录可供后续质检与纠纷处理。

参与角色： 消费者、客服坐席、IM 网关（EMQX/MQTT）、会话分配与路由服务。

flowchart TD
    userStart[消费者发起咨询]
    assignAgent[系统分配客服]
    mqttConnect[建立MQTT连接]
    exchangeMsg[双方收发消息]
    handleIssue[客服处理问题]
    closeSession[结束会话]
    userStart --> assignAgent
    assignAgent --> mqttConnect
    mqttConnect --> exchangeMsg
    exchangeMsg --> handleIssue
    handleIssue --> closeSession

步骤说明：

用户在客户端点击咨询入口，创建或恢复会话请求。
会话服务根据排队规则、技能组或负载将会话分配给可用客服。
客户端通过 MQTT 与 EMQX 建立长连接，订阅会话主题并完成鉴权。
双方消息经 IM 服务路由，经 MQTT 实时推送到对端，消息持久化可选。
客服在工单或订单上下文中处理用户问题，可发送文本、图片等（以产品能力为准）。
用户或客服结束会话，释放坐席并归档会话记录。

说明与规则：

连接需带用户与租户身份，防止串台；断线重连应恢复最近会话上下文。
消息体大小与频率宜有限流，避免恶意刷屏影响 EMQX 与下游服务。

5. 邮件模板与发送流程

管理员配置 SMTP 等邮件发送服务后，创建邮件模板并绑定触发条件（如注册成功、订单发货）；事件发生时系统自动渲染模板并发送，运营可在发送记录中查询状态与失败原因。

参与角色： 平台管理员、邮件服务（SMTP）、业务事件源、邮件发送与记录服务。

flowchart TD
    smtpConfig[配置SMTP等发信参数]
    mailTpl[创建邮件模板]
    bindTrigger[设置触发条件]
    evtOccur[业务事件发生]
    renderSend[渲染并发送邮件]
    logView[查看发送记录]
    smtpConfig --> mailTpl
    mailTpl --> bindTrigger
    bindTrigger --> evtOccur
    evtOccur --> renderSend
    renderSend --> logView

步骤说明：

在系统设置中配置发件域名、SMTP 地址、端口、账号及加密方式，并完成连通性校验。
创建邮件模板：主题、HTML/纯文本正文，可含与消息模板类似的变量占位符。
为模板绑定触发条件，例如「订单支付成功」「发货」「退款申请已受理」等。
对应业务事件发生时，邮件服务拉取模板与变量数据。
渲染邮件后通过 SMTP 投递，并异步更新投递状态（成功、退信、拒收等）。
管理员在发送记录中按时间、收件人、状态筛选，用于对账与问题排查。

说明与规则：

大批量营销邮件与交易类邮件宜分通道或子账号，降低主站交易邮件信誉风险。
需遵守 CAN-SPAM 等区域法规时，退订与发件人信息应在模板中体现。

6. 消息模板多语言翻译流程（跨境版）

【overseas 版】消息模板在库中保存原文与变量定义；发送侧仍按存储的原文与变量参与匹配；用户读取展示时，根据用户语言偏好选择翻译后的模板文案，再填入变量值，最终展示本地化内容。

参与角色： 运营人员、翻译资源或翻译管理、消息模板服务、终端用户。

flowchart TD
    storeOrigin[存储原文模板与变量]
    sendMatch[发送时按原文匹配模板]
    readRequest[用户读取消息]
    resolveLang[解析用户语言偏好]
    loadTranslation[加载对应语言译文]
    fillValues[用变量值填充译文]
    displayLocalized[展示本地化内容]
    storeOrigin --> sendMatch
    sendMatch --> readRequest
    readRequest --> resolveLang
    resolveLang --> loadTranslation
    loadTranslation --> fillValues
    fillValues --> displayLocalized

步骤说明：

在跨境版中为每条模板维护默认语言原文及变量列表，并可维护多语言译文条目。
触发通知时，系统仍使用原文模板键与变量参与路由与存储，保证与境内逻辑一致、便于对账。
用户打开消息中心或推送详情时，请求携带或推断用户语言（账户设置、站点语言等）。
消息服务根据语言解析结果选取已审核的译文；若无译文则回退到默认语言原文。
将业务侧变量值按占位符规则填入译文，生成最终展示字符串。
前端展示翻译后的标题与正文；日志与运营后台可仍查看原文与变量快照。

说明与规则：

变量名在每种语言译文中应保持一致，避免翻译误改占位符导致无法替换。
译文发布前建议走审核流程；缺失译文时回退策略需在产品中明确告知运营方。