離線訊息總遺失？即時通訊離線訊息收不到的常見原因與修復

先定位：丟的是離線儲存還是重連拉取

傳送方顯示「已傳送」，接收方重新上線後仍收不到，先對照三種現象：所有裝置都收不到，是伺服器端沒有寫入離線佇列；只有某台裝置收不到，是用戶端重連後沒有依會話補拉；同一帳號多台裝置訊息互相覆蓋，是多端同步策略有誤。判斷清楚再動手，避免盲目換伺服器或改協定。

最容易忽略的三個原因

• 離線訊息佇列未啟用或 TTL 過短。伺服器端只做即時轉發，未依接收者 ID 儲存，或過期時間太短，稍晚上線訊息已被清理。
• WebSocket 斷線後沒有持久會話與補拉機制。用戶端重連後不帶本地最後訊息 ID 或時間戳同步，斷線期間訊息不返回。使用 WebSocket 實現即時通訊時，連線只是通道，不能替代離線儲存和補拉。
• 多端同步依「最新端」覆寫，而不是依訊息 ID 去重。多裝置同時上線時，狀態同步被誤當成確認，導致未拉取的訊息被標記為已讀或清除，表現為重複推播或遺失。

修復步驟：依鏈路逐一補齊。

1. 伺服器端開啟離線儲存並設定合理的 TTL。依接收者 ID 寫入獨立佇列，至少保留 7 天；群聊依成員維度寫入。
2. 用戶端重新連線後帶游標補拉。用本地最大訊息 ID 或最後同步時間請求增量訊息，依 ID 合併，涵蓋重新連線和前景恢復。
3. 多端同步改為去重合併。伺服器端下發全域唯一 ID，用戶端依 ID 去重，不依「最後上線裝置」覆寫，同時避免離線遺失和重複推播。
4. 連線失敗先排查心跳與升級路徑。若 WebSocket 頻繁斷開，檢查心跳間隔、代理逾時和行動網路切換；必要時退回 HTTP 長輪詢。排查連線失敗時，先看用戶端是否取得重新連線事件，再查會話是否失效；同時確認心跳延遲，避免把延遲高誤判為離線遺失。

驗證與邊界：私有化與 SaaS 差異

弱網下關閉應用程式再重新開啟、斷網 10 分鐘後恢復、同一帳號雙裝置同時在線，三組都能收到且不重複，代表鏈路完整。私有化部署可自訂 TTL 與多端同步；SaaS 受平台限制。企業 IM 私有化與 SaaS 對比，離線訊息是剛需時優先看私有化是否暴露離線佇列參數，可參考三方 IM 即時通訊系統客製化開發與私有化部署解決方案。即時通訊軟體怎麼選，不能只看即時到達率，還要把離線補償當作驗收項。自建方案要關注訊息可靠性隱性成本，成本拆解：自建即時通訊需要多少錢，包含哪些隱性支出有完整科目。