工作总结
发表时间：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进程导致没有展示。这比说“我们系统没问题”管用多了。
以后的方向，我想把消息可达率的监控做得更细。现在是抽样探测，总归有盲区。如果能做到每一条消息的端到端可观测，在用户投诉之前就主动发现丢消息，那才算真正把活干透了。
就这些。改天有空再聊聊消息顺序乱序的问题，那个坑比今天说的这些加起来都深。
- 更多精彩工作总结内容，请访问我们为您准备的专题：工作总结
