企业 OA 为什么要内置一套 IM？RuoYi Office 即时通讯功能全介绍：单聊/群聊/频道/音视频/审批协同 PC+App 双端打通

企业 OA 为什么要内置一套 IM？RuoYi Office 即时通讯功能全介绍：单聊/群聊/频道/音视频/审批协同 PC+App 双端打通

🌐 文档地址：http://ruoyioffice.com | 📦 源码1·GitHub：ruoyi-office | 📦 源码2·GitCode：ruoyi-office | 📦 源码3·Gitee：ruoyi-office | 💬 微信：17156169080（备注「RuoYi Office」）

“公司都有微信/钉钉了，OA 还搞什么 IM？”——这是很多人第一反应。但真到用的时候你会发现：审批消息淹没在几十个微信群里、找同事得先加好友、离职员工还留在群里看资料、聊天记录散落在私人账号上，公司完全管不到。RuoYi Office 内置的 IM 即时通讯，解决的不是“能不能聊天”，而是“聊天能不能和组织、权限、审批、数据长在一起”——同事无需加好友、审批可一键沟通、消息全程可管可控，PC 与手机双端打通。

▲ 一眼看懂：组织免加好友 · 审批一键沟通 · 数据自主可控

引言：企业为什么要“自己的 IM”，而不是用微信群？

微信、钉钉当然能聊天，但用它们承载企业沟通，会遇到几个绕不过去的坎：

沟通和组织脱节：新同事得先互相加好友、拉群，人一多就乱；员工离职，微信群里还留着，公司资料照样能看。

审批和聊天两张皮：一条审批在 OA 里躺着，催办得再去微信上戳一句“帮我看下那个单子”，上下文全靠人肉搬运。

数据不在自己手里：聊天记录、文件都存在员工私人账号和第三方服务器上，一旦离职、封号，企业沉淀的沟通资产说没就没。

多个系统各发各的消息：OA 发一条、CRM 发一条、审批发一条，员工被通知轰炸，重要的反而被淹没。

一句话结论：企业 IM 的价值不在“聊天”本身，而在它与组织、权限、审批、数据的“原生打通”——这正是外挂式微信群给不了的。

▲ 内置 IM 主界面：左侧会话列表（含未读、在线状态、群聊/单聊），右侧消息区实时收发；顶部导航与整个平台一致——IM 就长在业务系统里，而不是另开一个 App

一、产品概览：一套 IM，两种形态

RuoYi Office IM 是内置在平台里的即时通讯能力，与整套系统共用同一份组织架构和账号体系。 为覆盖不同深度的需求，产品提供了两种协同互补的形态：

两种形态共用同一条 WebSocket 长连接（/infra/ws），都建立在平台统一的用户、组织、权限之上——区别只是能力深度不同，账号和组织始终是同一套。

▲ 全功能 IM 独立界面：左侧会话与频道、右侧消息区，底部输入栏内置图片、文件、语音、视频通话等入口——是一套完整的企业级 IM 产品形态

二、功能架构：消息是怎么“实时又不丢”的

IM 的核心难点，是“既要实时，又不能丢消息”。 RuoYi Office 用“WebSocket 实时推送 + 落库持久化 + 离线补偿”的经典三段式来保证：

▲ 消息发送与触达时序：发送方 → WebSocket 入站 → 消息落库 → 更新会话摘要与未读数 → 在线者实时推送、离线者上线后 pull 补偿 → 已读回执回写

一条消息从发出到对方看到，经历这样几步：

统一的 WebSocket 通道让 IM 与整个平台的实时能力复用同一条链路：

# application.yaml（节选）—— 全平台共用一条 WebSocket 长连接
# IM 消息、通知、审批提醒都走同一条通道
websocket:
enable: true
path: /infra/ws

服务端下发消息时，用统一的消息类型区分 IM 与其它通知，前端按类型分发到会话或角标：

// IM 实时通知统一封装，前端据 type 路由到会话/未读角标
public class ImNotificationWebSocketDTO {
public static final String TYPE = "im-notification";
private Integer conversationType; // 单聊/群聊/频道
private Integer contentType; // 文本/图片/文件/语音/视频…
private Object payload; // 消息体
}

三、能力清单：从单聊到音视频

RuoYi Office IM 的能力覆盖了主流企业 IM 该有的样子。 下面这张能力矩阵，能帮你快速判断它够不够用：

▲ IM 能力矩阵：会话形态（单聊/群聊/频道）× 消息类型（文本/图片/文件/语音/视频/@/表情/名片/合并转发）× 协同能力（已读回执/撤回/离线补偿/音视频通话/审批联动）

3.1 会话形态

▲ 通讯录：新的朋友（好友申请）、群聊、好友分组一目了然；企业内沟通既支持“组织架构直接选人”，也支持“好友体系”两种关系模型

3.2 消息类型

支持文本、图片、文件、语音、视频、@提及、表情包、名片、合并转发等丰富消息类型；群消息支持 @某人 精准提醒；重要消息可撤回。

3.3 协同能力

四、杀手锏：IM 与审批的原生打通

这是内置 IM 相比微信群最不可替代的一点。 在 RuoYi Office 里，审批和沟通不是两张皮：当你在 BPM 审批详情页看到一条待办，可以一键对相关审批人发起会话，并自动带上流程上下文（流程名、实例信息），对方一看就知道你在催哪个单子，不用再复制粘贴“帮我看下那个报销”。

// 审批详情页一键沟通：带上流程上下文发起 IM 会话
startConversationFromProcessInstance({
userId, // 目标审批人（来自组织架构）
processInstanceId, // 流程实例
processInstanceName, // 流程名称，进入会话即带上下文
});

这背后的逻辑是：IM 的“人”就是 HRM 的员工、就是 OA 的审批人、就是组织架构里的同事——同一个身份，天然可被任意业务模块调用。这正是“一体化平台”内置 IM 的独特价值。

五、多端体验：PC 管理端 + UniApp 移动端

沟通天然是移动优先的，所以 IM 必须双端打通。 RuoYi Office IM 在 PC 管理端与 UniApp 移动端保持同源，同一账号登录，消息实时同步：

移动端与 PC 端 API 同构、消息同源，本地还用 IndexedDB / SQLite 做消息缓存，保证移动端首屏快、离线可看历史。

六、快速体验

在线演示

• 🌐 Web 演示：http://ruoyioffice.com/web/（账号 admin / 密码 admin123）
• 📱 App 演示：http://ruoyioffice.com/app/

推荐体验路径

源码仓库

常见问题（FAQ）

已经有微信/钉钉了，还需要内置 IM 吗？

需要的场景很明确：当你希望沟通与组织架构、审批流程、企业数据原生打通，且聊天数据要留在企业自己手里时，内置 IM 才做得到。微信群适合临时沟通，但管不了组织、接不了审批、留不住数据。

IM 是怎么保证消息不丢的？

采用“WebSocket 实时推送 + 消息落库 + 离线补偿”三段式：消息先落库保证持久化，在线者实时推送，离线者上线后通过拉取接口补齐，客户端消息 ID 做幂等去重。

支持群 @、已读回执和音视频通话吗？

支持。群消息可 @某人；单聊“已读”、群聊“N 人已读”回执；全功能形态基于 LiveKit 提供一对一/多人音视频通话。

移动端和 PC 端是同一套吗？

是。后端 API 同源，PC（Vben）与移动端（UniApp，可发布 H5/小程序/App）消息实时同步，同一账号登录即用。

IM 和平台其它模块是什么关系？

IM 的“人”就是系统里的用户、HRM 的员工、审批流程里的审批人——同一套账号和组织，所以审批可以一键沟通、消息可随组织变更收权，这是一体化平台内置 IM 的独特价值。

结语

企业沟通工具的选择，本质是一个问题：你希望沟通“挂在”业务系统外面，还是“长在”业务系统里面？

微信群把沟通挂在外面，方便却失控；RuoYi Office 内置 IM 把沟通长在里面——同事无需加好友、审批可一键沟通、消息全程可管、数据自主可控，PC 与手机双端打通。如果你的团队正被“审批淹没在微信群、聊天记录管不到”困扰，不妨用 admin/admin123 上手点一圈，感受“沟通即协同”的体验。

💡 想要体验 RuoYi Office 的强大功能？

🌐 在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）

💬 技术咨询：添加💬 17156169080，备注「RuoYi Office」

⭐ 如果觉得不错，请给个 Star 支持一下！