Q聊天架构里的核心模块通常有哪些？我在阅读聊天系统时，常常分不清消息收发、在线状态、群组管理这些能力分别由哪些部分负责，应该从哪些模块入手理解整体架构？
A从消息流、连接层和业务层理解
可以把聊天架构拆成三层来看：连接层负责维持客户端在线与长连接通信，消息层负责接收、转发、存储与投递消息，业务层负责用户关系、群聊、会话列表、通知等能力。理解这三层的职责边界，就能快速看清架构的主线。
Q聊天系统为什么需要长连接，而不是普通请求？如果只是发消息，为什么很多聊天应用还要保持长连接？这种设计对实时性和稳定性有什么影响？
A长连接是为了降低延迟
聊天场景强调消息实时到达，长连接可以让服务端主动把新消息推送给客户端，避免客户端频繁轮询。它还能减少握手开销，提升在线状态感知和消息投递效率，因此更适合即时通讯。
Q消息发送后是怎么保证对方能收到的？我想理解聊天系统里的消息可靠性设计，比如对方离线、网络波动或重复发送时，系统通常怎么处理？
A依靠确认、重试和离线补偿
常见做法是给消息设计唯一标识，并通过发送确认、服务端存储、重试投递和离线消息补发来提高可达性。即使接收方暂时不在线，系统也能在其重新上线后补发未读消息，从而减少丢消息的风险。
Q单聊和群聊在架构上有什么不同？从系统设计角度看，单人对话和多人群聊会带来哪些不同的处理方式，为什么群聊通常更复杂？
A群聊更关注分发效率
单聊主要是点对点投递，路径相对简单；群聊则需要把同一条消息分发给多个成员，还要考虑成员规模、离线补发、已读状态和权限控制。群聊的复杂度通常来自消息扇出、存储成本和状态同步。