工作總結
發表時間：2026-04-152026年即時通訊工作總結。
做IM開發三年，我有個習慣：手機24小時開著推送，不是怕漏接電話，是怕監控報警。這行當里，凌晨三點的報警聲比任何鬧鐘都管用。
先說去年栽的那個跟頭。群聊語音消息上線當天下午，監控突然跳出紅點——消息收發延遲從80毫秒飆到3秒多，CPU像過山車。我第一反應是數據庫連接池炸了，查了一圈不是。又看CDN，也不是。那會兒用戶已經開始在群里刷“發不出語音了”，運營同事在釘釘上每隔五分鐘問一次“好了沒”。
說實話，那四十分鐘是我今年最慌的時候。后來抓包才發現，客戶端把15秒的語音文件轉成了base64字符串，直接塞進JSON體里，一段語音的元數據干到200KB。而我們消息體的上限是64KB——當初設計文檔里寫著“理論上不會超過”，這就是典型的拍腦袋。
臨時方案怎么做的？讓語音消息先走對象存儲，消息體里只存URL。但問題來了：改這個邏輯，客戶端必須發版。發版要經過測試、審核，最快也得兩天。等不了。最后我做了個臟活——服務端臨時開了一個兼容接口：如果檢測到消息體超限，自動把body里的base64截出來上傳到OSS，再把URL替換進去。這個接口只存活了40分鐘，等客戶端新版本覆蓋到80%用戶后就下線了。那40分鐘里我蹲在工位上盯著日志，生怕這個補丁又捅出別的簍子。
后來徹底解決，是換了protobuf加gzip壓縮，同樣一段語音消息的元數據從12KB壓到1.2KB。但這件事給我的教訓不是技術層面的，是流程上的：以后任何涉及消息體大小的改動，必須在壓測環境里用最極端的參數跑一遍。我后來寫了一份《消息體設計規范》，規定所有二進制數據不得進JSON，必須走獨立通道。這條規范現在掛在團隊Wiki的置頂位置。
再說一個產品層面的坑。用戶反饋“已讀回執不準”的工單，很長一段時間穩居前三。查代碼發現邏輯很簡單粗暴：消息只要到了客戶端本地數據庫，就上報已讀。但用戶根本沒看到——消息折疊在通知欄里，或者手機息屏。用戶罵的是“你們這功能騙人的吧”，我聽著刺耳，但確實沒法反駁。
怎么改？我翻了三天工單，把所有抱怨已讀不準的對話場景列了個表。發現規律：80%的投訴發生在群聊里，而且是在用戶快速滑動消息列表的時候。于是設計了三態模型：送達→展示→已讀。展示狀態需要消息對應的View在屏幕上停留超過300毫秒才觸發。這個閾值不是拍腦門，我拿了100個用戶的操作軌跡做統計，取的中位數。
上線后投訴確實少了，但新問題來了。有用戶反饋“我明明看了消息，對方還是顯示未讀”。查日志發現，用戶在群聊里快速上滑，曝光埋點觸發了，但展示狀態還沒來得及上報到服務端，用戶就退出了聊天界面。本地隊列的方案就是這時候加的——所有狀態變更先落本地SQLite，退出時統一補報。為了這個補報時機，我試過監聽onPause、onStop、onDestroy，每種都有坑，最后用了onWindowFocusChanged配合延時重試。
改完后的數據：抽樣統計1000條消息，已讀回執準確率從87%提升到99.2%。那剩下的0.8%是什么？是用戶恰好卡在300毫秒臨界值上滑走，或者手機內存不足導致上報線程被殺死。這些邊界情況我至今沒完全解決，但已經不影響絕大多數用戶了。
還有件事我一直沒好意思寫進周報。有一次我自作聰明，把消息拉取的批量大小從20條改成50條，想減少網絡請求。結果低端機直接OOM，用戶反饋“一打開聊天就閃退”。回滾后我老老實實做了動態批量——根據設備可用內存自動調整，512M以下的機器用10條，2G以上用50條。這個方案后來被組里其他項目拿去用了，算是因禍得福。
質量驗收這塊，我們每個月搞一次混沌演練。不是走形式，是真斷網、真切機房、真改系統時間。上個月演練時發現一個隱藏bug：NTP時間跳變后，消息重試隊列的退避算法里用了System.currentTimeMillis()做比較，結果時間往回跳了，導致所有待重試的消息全部進入死信隊列。那天晚上改完代碼，我在復盤報告里寫了一條硬性規定：所有涉及時間的邏輯，一律用單調時鐘(System.nanoTime)或者自己維護一個遞增序列號。
你要問我這兩年最大的認知變化是什么？我覺得是對“可靠性”的理解變了。剛入行時覺得可靠性就是消息不丟、不亂序。現在我覺得，可靠性還包括“用戶罵你的時候你知道為什么”。所以我花了很多時間在日志染色上，每一條消息從發送到落地的全鏈路，都能用traceId串起來。用戶說“我的消息丟了”，我能在十分鐘內告訴他：消息到達了服務器，推給了對方，對方手機收到了但系統殺掉了APP進程導致沒有展示。這比說“我們系統沒問題”管用多了。
以后的方向，我想把消息可達率的監控做得更細。現在是抽樣探測，總歸有盲區。如果能做到每一條消息的端到端可觀測，在用戶投訴之前就主動發現丟消息，那才算真正把活干透了。
就這些。改天有空再聊聊消息順序亂序的問題，那個坑比今天說的這些加起來都深。
- 更多精彩工作總結內容，請訪問我們為您準備的專題：工作總結
