企业即时通讯选型，功能点太多，很多技术术语容易让人绕进去。"后台在线"和"离线推送"，就是其中一对常被混淆的概念。它们看起来相似，实际上指向两种完全不同的运行机制——搞清楚这两个概念，对判断一套企业IM系统的通知可靠性，很有帮助。
"后台在线"指的是：用户虽然没有打开IM应用界面，但应用进程仍在后台保持与服务器的连接状态，消息可以实时推送到设备，不需要额外的推送通道。
从技术上说，这是一种"长连接保活"机制。应用在后台维持着与服务端的TCP或WebSocket连接，服务器一旦有新消息，就可以直接推送到客户端，延迟通常在毫秒到秒级。
这种机制在PC端和内网环境表现比较稳定。PC端应用天然容易在后台保持进程，内网环境也没有运营商省电策略的干扰，长连接相对容易维持。
在移动端，情况更复杂。
Android和iOS系统出于省电和内存管理的目的，都会对后台进程有不同程度的限制。特别是国内安卓设备，各厂商的定制系统（MIUI、EMUI、ColorOS等）对后台进程的管控力度差异很大，有些设备在锁屏一段时间后会主动杀掉后台进程，导致长连接断开。
这也是"离线推送"存在的原因。
"离线推送"指的是：当IM应用进程被系统杀死、或完全退出后，借助操作系统或厂商提供的推送通道，将消息以通知形式下发到设备。
此时IM应用本身已经不在运行，消息通知是由系统级推送服务完成的，用户点击通知后，才会重新拉起IM应用。
| 平台 | 常用推送通道 | |---|---| | iOS | APNs（Apple Push Notification service） | | Android（国际） | FCM（Firebase Cloud Messaging） | | Android（国内） | 各厂商推送通道：小米推送、华为推送、OPPO推送、vivo推送等 | | 国产信创系统 | 需要适配对应系统推送能力或自研通道 |
国内安卓生态的离线推送，实质上是走各厂商的系统级推送通道，这类通道优先级更高，不受普通后台进程限制。理论上即使IM进程已经被杀死，用户也能收到通知。
离线推送不是万能的，存在几类常见情况：
用一句话概括：
后台在线是IM自己维持的连接，消息实时到达；离线推送是系统帮忙转发通知，应用本身已不在运行。
| 维度 | 后台在线 | 离线推送 | |---|---|---| | 应用状态 | 进程在后台运行 | 进程已被杀死或退出 | | 依赖渠道 | IM自身长连接 | 系统/厂商推送服务 | | 消息内容 | 可获取完整消息 | 通常只能获取通知提示 | | 延迟 | 低（毫秒到秒级） | 相对较高，受推送通道影响 | | 私有化内网适配 | 天然适配内网 | 需要专门处理内外网隔离 | | 信创系统适配难度 | 相对可控 | 需专项适配或自研推送通道 |
对于政府、国企、金融等有内网隔离需求的组织，后台在线的长连接稳定性更关键。这类场景中，消息推送不能依赖外部推送通道，否则内网消息要绕到外网再回来，既有安全隐患，又可能根本不通。
可以在评估时重点问清楚：
对于员工分散办公、经常需要与外部联系人协同的组织，离线推送的覆盖面和稳定性同样不可忽视。用户不可能永远保持应用活跃，离线推送决定了他们能不能在最短时间内收到重要通知。
值得核查的点：
信创办公场景中，终端设备可能使用国产操作系统，推送机制与主流安卓/iOS差异较大。部分国产系统没有标准的第三方推送通道接入框架，IM系统需要自研推送能力，或依赖系统厂商提供的专属接口。
这一点在通用IM产品中容易被忽略，但在强信创要求的项目中，往往会成为实际落地的卡点。选型时应提前确认目标终端环境，并要求厂商提供信创终端上的实际测试记录。
"后台在线"和"离线推送"，解决的是同一个问题的不同阶段：一个保障的是"应用活着的时候能不能实时收消息"，另一个解决的是"应用被杀掉了还能不能收到通知"。
对大多数组织来说，两套机制缺一不可，但不同场景的侧重点不同。内网私有化环境优先把长连接保活做稳；外网和混合场景，离线推送的覆盖面和延迟同样关键。
选型时不只是问"支不支持"，更要问清楚具体机制、测试数据和内网适配方案。
来源：结合小天互连在企业即时通讯场景中的实际服务经验整理。
