即时通讯离线消息架构，解决的不是“用户不在线时把消息先存起来”这么简单，而是要保证消息在网络断开、终端退出、多端切换、服务重启、用户重新上线等复杂情况下，仍然能够尽量做到不丢、不乱、不重复、可追溯。对企业即时通讯系统来说，离线消息能力直接影响消息可靠性、群聊一致性、审计留存和私有化部署环境下的长期稳定运行。
在企业级即时通讯架构中，离线消息通常需要和消息路由、长连接、MQ 队列、ACK 确认、Redis 在线状态、数据库持久化、多端同步和上线补发机制共同工作。单独只做“离线消息表”，并不能构成完整的可靠投递体系。
即时通讯离线消息的完整流程，可以概括为四个关键动作：先判断接收方是否在线，再通过 MQ 保障消息可靠流转，然后根据 ACK 确认结果决定是否进入离线存储，最后在用户上线时按序补发并完成确认。
从技术架构角度看，离线消息至少要解决五个问题。
第一，消息不能丢。发送端提交成功后，服务端要有可靠机制接住消息，不能因为接收方离线、网络抖动或服务异常就丢失。
第二，消息不能乱。用户上线后补发历史消息时，要按照会话维度、时间顺序或消息序列号进行恢复，避免消息顺序错乱。
第三，消息不能重复。网络重试、ACK 超时、客户端重复连接都可能导致重复投递，系统必须做幂等控制。
第四，消息要能追溯。企业即时通讯通常涉及消息审计和合规留痕，离线消息不仅要送达，还要能够形成完整记录。
第五，多端状态要一致。同一个账号可能同时登录 PC、移动端、Web 端，离线补发不能只考虑单一终端。
所以，离线消息架构不是一个边缘功能，而是企业即时通讯可靠投递体系的核心组成部分。
在个人聊天场景里，偶尔漏一条消息可能只是体验问题。但在企业即时通讯场景中，消息往往和业务动作绑定。
一条 OA 审批提醒没有到达，可能影响流程处理。
一条生产告警没有补发，可能影响现场响应。
一条项目群通知没有同步，可能影响跨部门协作。
一条金融业务沟通记录没有留存，可能影响后续审计。
因此，企业即时通讯不能只追求“在线实时推送”，还必须保证“离线后可恢复”。
尤其在私有化部署环境中，企业的网络结构更复杂。用户可能处在内网、专网、VPN、移动网络、分支机构网络、信创桌面端或外勤终端中。网络中断、终端休眠、移动端后台挂起、客户端重连、服务节点切换，都可能导致用户处于短暂离线状态。
如果没有完善的离线消息架构，即时通讯系统就很难支撑真实企业办公。
要理解离线消息，不能把它孤立看。它处在完整消息链路中的中后段。
一条企业即时通讯消息通常会经历以下流程：
发送端提交消息；
接入层接收请求；
服务端做身份校验；
消息路由模块判断接收方和会话关系；
在线状态服务判断用户是否在线；
在线用户通过长连接实时推送；
离线用户进入离线存储或待投递队列；
接收端返回 ACK 确认；
服务端更新消息状态；
用户上线后触发离线补发；
客户端按序接收并再次确认。
也就是说，离线消息并不是消息发送失败后的“补丁”，而是消息路由系统的一部分。
如果接收方在线，消息进入实时投递链路。
如果接收方离线，消息进入离线投递链路。
如果接收方在线但 ACK 超时，系统还需要判断是终端未收到、客户端未处理、网络回包失败，还是服务端状态异常。
因此，离线消息架构必须与消息路由、长连接、ACK 和状态管理联动设计。
延伸阅读：即时通讯消息路由机制：一条消息是如何从发送端到达接收端的？
离线消息流程的起点，并不是“用户离线”，而是发送端提交消息。
发送端提交消息后，服务端首先要完成基础校验，包括发送人身份、会话关系、群组权限、消息类型、消息格式、发送频率和业务权限。
企业即时通讯不能只判断“用户是否登录”，还要判断“用户是否有权发送这条消息”。
例如：
发送人是否还在该组织内；
发送人是否有权限进入该群；
接收人是否仍然有效；
外部协作人员是否允许接收该类消息；
业务系统推送是否具备接口权限；
敏感消息是否需要特殊审计。
只有基础校验通过，消息才应该进入后续投递流程。
这一步非常重要。因为一旦非法消息进入 MQ 或离线存储，后续再处理会更复杂。对企业即时通讯来说，消息可靠投递必须建立在权限正确的前提下。
要实现离线消息不乱、不重复，消息 ID 和序列号设计非常关键。
一般来说，企业即时通讯系统至少需要两类标识。
第一类是全局消息 ID，用于唯一标识一条消息。它可以用于幂等判断、ACK 确认、日志追踪、审计记录和问题排查。
第二类是会话序列号，用于保证某个单聊、群聊或业务会话中的消息顺序。用户上线补发离线消息时，客户端可以根据序列号判断是否有缺口，是否需要拉取补偿消息。
如果系统只有时间戳，没有稳定序列号，就容易出现两个问题。
一是消息乱序。高并发群聊、跨节点投递、多端同步时，单纯依赖时间排序并不总是可靠。
二是补发不完整。客户端无法准确判断自己最后收到的是哪一条消息，也就难以恢复缺失消息。
因此，离线消息架构要在消息进入队列前，就完成消息 ID、会话 ID、发送方、接收方、消息类型、时间戳、序列号等基础元数据生成。
MQ 在离线消息架构中的作用，不只是“削峰填谷”，更重要的是承接消息可靠流转。
当发送端提交消息后，服务端不应该只依赖内存转发。因为内存队列一旦遇到服务重启、节点异常或网络抖动，就可能造成消息丢失。
引入 MQ 持久化后，消息可以先进入可靠队列，由后续投递服务异步消费。
MQ 在即时通讯离线消息架构中通常承担几类任务。
第一，削峰。 在群聊高峰、业务通知高峰、系统告警集中推送时，MQ 可以缓冲瞬时压力，避免核心服务被打满。
第二，解耦。 发送服务、路由服务、投递服务、离线存储服务、审计服务可以通过队列解耦，降低模块之间的直接依赖。
第三，可靠投递。 消息进入持久化队列后，即使下游消费服务短暂异常，也可以在恢复后继续消费。
第四，异步处理。 在线投递、离线入库、审计记录、业务回执等动作可以按不同队列拆分，提升整体吞吐能力。
但 MQ 不是万能的。企业即时通讯系统还需要处理消费确认、重复消费、消费失败重试、死信队列和消息状态更新，否则仍然可能出现重复投递或状态不一致。
消息进入投递流程后，系统需要判断接收方是否在线。
在线状态通常不会只存在客户端，而是由服务端统一维护。例如用户登录后建立长连接，服务端记录用户 ID、连接 ID、终端类型、所在节点、登录设备、在线时间等信息；用户断开连接、心跳超时或主动退出时，服务端再更新在线状态。
在企业即时通讯架构中，Redis 常用于维护在线状态、连接映射和临时路由信息。
在线状态判断通常要回答几个问题。
接收用户是否在线；
在线的是哪个终端；
PC 端、移动端、Web 端是否都在线；
用户当前连接在哪个服务节点上；
该终端是否允许接收这类消息；
用户是否刚刚断线但状态尚未过期；
是否需要向多个终端同时投递。
如果接收方在线，消息进入实时推送链路。
如果接收方离线，消息进入离线存储链路。
如果接收方状态不确定，系统通常需要结合心跳、连接状态、ACK 回执和超时策略进一步判断。
很多系统容易误以为“消息推送到长连接”就等于送达。实际上，在企业即时通讯中，推送成功并不等于客户端已经收到，更不等于用户已经看到。
因此，ACK 确认机制非常关键。
ACK 可以分为多个层级。
第一层是服务端接收 ACK。 表示发送端提交的消息已经被服务端成功接收。
第二层是投递 ACK。 表示服务端已经把消息投递到接收端所在连接或终端。
第三层是客户端接收 ACK。 表示客户端已经收到消息并写入本地消息列表。
第四层是业务已读 ACK。 表示用户已经打开会话或阅读消息。
不同企业即时通讯系统对 ACK 层级的设计不完全一样，但至少要区分“发送成功”和“接收成功”。
如果服务端向在线用户推送消息后，没有收到客户端 ACK，就需要进入重试、补偿或离线存储逻辑。否则，网络抖动时消息可能看似发送成功，实际接收端并没有收到。
因此，ACK 是判断消息是否真正进入下一状态的关键依据。
ACK 超时是离线消息架构中的常见情况。
例如，接收方刚刚断网，但服务端在线状态还没过期；移动端被系统挂起，长连接未及时释放；客户端收到消息后还没来得及回 ACK；网络回包失败，服务端没有收到确认。
这时，系统不能简单判定消息已经送达。
更合理的做法，是根据 ACK 超时策略进入补偿流程。
常见处理方式包括：
短时间内重新投递；
检查连接状态是否仍然有效；
判断用户是否已经断线；
将消息写入待确认队列；
超过阈值后转入离线消息存储；
用户重新上线后再进行补发校验。
这里要注意，ACK 超时并不一定代表消息没有到达。因此，后续补发时还要依赖消息 ID 做幂等判断，避免客户端重复显示。
对企业即时通讯来说，ACK 超时处理要兼顾可靠性和体验。如果过早重试，可能造成重复消息；如果完全不重试，可能造成消息丢失。
离线消息存储不是简单把整条消息复制进一张表。
在更合理的设计中，消息内容和投递状态应该分层处理。
消息内容可以进入消息主表或消息存储层，记录消息 ID、会话 ID、发送人、消息类型、内容摘要、发送时间、序列号、审计字段等信息。
投递状态可以进入用户维度或终端维度的投递表，记录某个用户、某个终端、某条消息的投递状态。
这样设计有几个好处。
第一，减少重复存储。同一条群消息不必为每个成员完整复制一份消息体。
第二，便于多端同步。同一账号的 PC 端、移动端、Web 端可以分别记录同步状态。
第三，便于已读未读管理。系统可以根据用户维度更新消息状态。
第四，便于补发。用户上线后，可以根据最后确认的序列号或投递状态拉取缺失消息。
第五，便于审计。消息内容和投递行为都可以被记录，但又能保持结构清晰。
对大规模群聊和高频业务通知来说，消息体与投递状态分离，是控制存储成本和提升补发效率的重要设计。
用户重新上线后，离线消息补发流程开始执行。
一般来说，客户端登录或长连接建立成功后，会向服务端提交自己的同步状态，例如最后收到的消息序列号、最后已确认的消息 ID、终端类型、登录时间和会话状态。
服务端根据这些信息判断是否需要补发。
典型补发流程包括：
客户端建立连接；
服务端完成身份认证；
服务端读取用户在线状态并绑定连接；
客户端上报最后同步位置；
服务端查询该用户未确认消息；
服务端按会话和序列号排序；
服务端分批推送离线消息；
客户端写入本地消息库；
客户端返回 ACK 确认；
服务端更新投递状态；
必要时触发已读、未读和多端同步。
这里最关键的是“按序补发”和“分批补发”。
如果离线消息很多，不能一次性全部推送，否则可能造成客户端卡顿、服务端瞬时压力升高或网络拥塞。更稳妥的方式是分批拉取、分页同步、按会话恢复。
离线补发最容易出现的问题之一，是重复消息。
重复消息可能来自多个环节。
发送端重试提交；
MQ 重复消费；
服务端 ACK 超时后再次投递；
客户端断线重连后重复拉取；
用户多端同时上线；
服务端状态更新延迟。
因此，离线消息补发必须做幂等控制。
常见做法是以消息 ID 作为客户端本地去重依据。客户端收到消息后，先判断本地是否已有相同消息 ID。如果已经存在，则不重复展示，只更新状态。
服务端也需要根据投递状态判断是否需要再次投递。如果某个终端已经确认接收，就不必重复补发；如果只是某个端收到，另一个端未同步，则要按终端状态处理。
幂等设计的目标，不是保证系统永远不会重复投递，而是保证即使发生重复投递，用户也不会看到重复消息，业务状态也不会重复执行。
即时通讯消息顺序，不宜只按全局时间排序。
因为不同会话之间的消息本来就可以并行，但同一个会话中的消息顺序必须尽量稳定。
例如，一个项目群里连续发送三条消息：
第一条是任务说明；
第二条是补充文件；
第三条是负责人确认。
如果用户上线后收到顺序变成第三条、第一条、第二条，理解成本就会明显增加。
因此，离线消息补发通常要以会话为单位维护序列。
对单聊来说，可以按双方会话序列补发。
对群聊来说，可以按群会话序列补发。
对业务通知来说，可以按业务会话、通知类型或时间线补发。
客户端收到离线消息后，如果发现序列号存在缺口，应主动向服务端发起补偿拉取。这样即使某一批推送失败，也能通过拉取机制恢复完整消息。
企业即时通讯通常不是单端使用。一个员工可能同时登录 PC 客户端、移动端、Web 端和信创桌面端。
多端同步会让离线消息处理更复杂。
例如：
PC 端在线，移动端离线；
移动端收到消息，PC 端未收到；
用户在 PC 端已读，移动端是否同步已读状态；
Web 端短暂登录后退出，是否还要保存补发状态；
一个端删除或撤回消息，其他端如何同步。
因此，离线消息架构不能只维护“用户是否在线”，还要维护“用户的哪些端在线”。
更合理的设计，是把在线状态、投递状态和已读状态分开。
在线状态回答：这个用户当前有哪些连接。
投递状态回答：这条消息是否已经投递到某个用户或终端。
已读状态回答：用户是否已经阅读或处理这条消息。
这三类状态不能混在一起。否则，系统很容易出现“移动端读了，PC 端还显示未读”或“PC 端收到，移动端上线后丢消息”的问题。
群聊是离线消息架构的压力场景。
单聊只涉及一个接收方，而群聊可能涉及几十、几百甚至上千成员。企业内部项目群、部门群、业务群、通知群都可能产生大量离线投递。
群聊离线消息要解决几个问题。
第一，群成员权限变化。用户离线期间被移出群，重新上线后是否还能收到离线期间消息，要看企业规则和权限策略。
第二，群消息扩散压力。不能简单为每个成员复制完整消息体，否则存储压力会快速放大。
第三，补发顺序控制。群消息必须按群会话序列恢复，避免上下文错乱。
第四，已读未读统计。群聊中谁已读、谁未读、是否需要提醒，都需要单独状态管理。
第五，消息撤回与删除。用户离线期间某条消息被撤回，上线后是否还补发原消息，需要根据撤回状态判断。
因此，群聊离线消息通常更依赖“消息体共享 + 用户投递状态 + 会话序列 + 权限校验”的组合设计。
企业即时通讯不只是员工之间聊天，还会接收 OA、ERP、门户、审批系统、告警系统、项目管理系统等业务通知。
这些业务系统消息同样需要离线补发。
例如，审批待办提醒、系统告警、会议通知、项目变更、工单状态、生产异常，如果用户离线时没有保存，重新上线后就可能错过重要事项。
但业务系统消息和普通聊天消息有一个差异：它往往带有业务状态。
例如，某个审批提醒在用户上线前已经被其他人处理，是否还需要补发？某个告警已经恢复，是否还需要显示原始告警？某个会议通知已经取消，是否还要推送旧消息？
因此，业务系统消息的离线补发，需要和业务状态校验结合。
更合理的方式是：即时通讯系统负责消息可靠投递，业务系统负责状态有效性判断。用户上线后补发时，可以根据消息类型决定是否展示最新状态、历史提醒或失效提示。
延伸阅读：企业即时通讯技术架构全解：服务端、多端、信创适配全覆盖
离线消息架构不能只追求可靠性，也要考虑安全。
在企业场景中，用户离线期间，权限可能发生变化。
例如：
员工离职；
员工调岗；
外部协作人员到期退出；
用户被移出项目群；
某个文件被设置为不可访问；
管理员关闭某类消息权限；
账号被安全冻结。
如果系统上线补发时不重新校验权限，就可能把离线期间积压的消息发给已经无权接收的人。
因此，企业级离线消息补发应当在关键场景下重新校验权限。
尤其是文件消息、敏感业务通知、外部协作消息、涉密群消息，更不能只按照“消息发送时用户在群里”来判断，还要结合企业安全策略。
对私有化即时通讯系统来说，离线消息、安全管控和审计留痕必须协同设计。
一个成熟的离线消息架构，要提前考虑异常情况。
常见异常包括：
发送端提交后网络中断；
消息进入 MQ 后消费失败；
服务端推送成功但客户端未回 ACK；
客户端收到消息但本地写入失败；
用户上线后补发过程中再次断线；
同一用户多端同时请求补发；
MQ 重复投递导致客户端收到重复消息；
数据库写入成功但状态更新失败；
群成员权限变化导致补发范围变化；
业务系统消息已经失效但仍在补发队列中。
这些异常看起来复杂，但本质都围绕三个问题：消息状态是否准确，投递记录是否可靠，客户端是否能幂等处理。
企业即时通讯系统如果只在正常网络下测试，很难发现这些问题。真正的技术验证，应当覆盖断网、弱网、重连、多端、服务重启、队列积压和权限变化等复杂场景。
企业在评估即时通讯离线消息架构时，可以重点看以下指标。
看是否有消息持久化机制。 发送成功后的消息是否进入可靠存储，而不是只依赖内存转发。
看是否引入 MQ。 是否通过 MQ 处理高并发、异步投递、消费重试和服务解耦。
看是否支持 ACK 确认。 是否区分服务端接收、客户端接收、用户已读等不同状态。
看是否有离线补发机制。 用户重新上线后，是否能按序拉取未接收消息。
看是否支持序列号。 客户端能否发现消息缺口，并触发补偿拉取。
看是否支持幂等去重。 重复投递、重复拉取、重连补发时，客户端是否能避免重复展示。
看是否支持多端同步。 PC、移动端、Web 端是否能保持消息状态一致。
看是否支持群聊离线。 大群、项目群、通知群中，离线消息是否仍能按序补发。
看是否结合权限校验。 用户离线期间权限变化后，补发是否仍能遵守安全规则。
看是否有审计留痕。 离线消息发送、存储、补发、确认是否能形成可追溯记录。
这些指标比单纯问“支不支持离线消息”更有价值。因为真正考验系统的是复杂状态下的可靠投递能力。
离线消息架构不是独立模块，而是企业即时通讯技术架构中的关键能力之一。
它依赖服务端接入层接收消息，依赖消息路由判断接收方，依赖长连接完成实时推送，依赖 MQ 做可靠流转，依赖数据库做持久化，依赖 Redis 或状态服务记录在线状态，依赖客户端 ACK 做投递确认，依赖多端架构完成状态同步。
因此，理解离线消息，需要把它放回完整技术架构中看。
小天互连企业即时通讯技术架构覆盖服务端、PC 端、移动端、Web 端、信创端、鸿蒙端、开放 API 和私有化部署环境。离线消息能力正是这套架构中支撑“消息不丢、状态可查、多端一致、业务可接入”的基础能力之一。
延伸了解：小天互连企业即时通讯技术架构
即时通讯离线消息架构的本质，不是把用户离线时的消息简单存起来，而是把所有“未送达、未确认、未同步”的状态，变成后续可以恢复、可以确认、可以追溯的技术流程。
MQ 持久化解决消息可靠流转问题，ACK 确认解决送达状态判断问题，离线存储解决用户不在线时的消息保留问题，上线补发解决重新连接后的消息恢复问题，幂等去重和序列号机制解决重复与乱序问题。
对企业即时通讯来说，离线消息能力越成熟，系统越能支撑真实办公环境中的弱网、断线、多端、群聊、业务通知和私有化部署场景。
所以，企业评估即时通讯系统时，不应只看“能不能发消息”，还要看消息在用户不在线、网络不稳定、终端切换、服务异常、权限变化时，能否依然做到可靠、安全、可恢复。
这也是即时通讯基础技术文章簇中，离线消息架构必须单独展开的原因。消息路由回答“一条消息如何找到接收方”，长连接回答“在线消息如何实时到达”，服务端架构回答“系统如何支撑整体运行”，而离线消息架构回答的是：当消息暂时没有送达时，系统如何保证它最终可恢复、可确认、可追溯。
