从踩坑到突破：开发微信小程序聊天功能时我如何解决沙盒与后台运行难题

去年接了个外包项目，客户要求在微信小程序里做个聊天功能。当时心想，不就是个即时通讯嘛，调个接口、绑个 WebSocket 就完事了。结果一上手才发现，这事儿远没那么简单。微信小程序的沙盒机制把 DOM 操作、全局变量、甚至原生 Socket 都封得死死的，想直接用 WebSocket 连服务器？可以，但必须自己处理心跳、重连、消息队列，还要防止用户切到后台时连接被系统掐断。更头疼的是，小程序没有真正的后台运行，用户一离开页面，所有定时器和网络请求都可能被回收。那段时间我天天盯着微信开发者工具的控制台，看那堆密密麻麻的日志，感觉比看股票 K 线还累。后来总算摸索出一套方案：用 WebSocket 做长连接，配合小程序的 onHide 和 onShow 钩子管理连接状态，再在 app.js 里搞个全局的 socket 实例，才算把基础通信稳住了。

真正让我抓狂的是消息的实时性和排序问题。用户发一条消息，你得让它立刻显示在聊天列表里，不能等服务器回复确认。这就意味着前端要先做乐观更新——消息发出后马上渲染到界面，用临时 ID 占位，等服务器回包后再替换成正式 ID。但乐观更新有个坑：如果用户同时发送多条消息，网络延迟不一致，服务器回包的顺序可能和发送顺序不同。比如用户先发了“你好”，再发了“在吗”，结果“在吗”的回包先到，“你好”后到，如果直接按回包顺序替换，消息列表就乱了。解决方法很简单也很笨：每发一条消息，前端生成一个本地时间戳加随机数组成的序列号，按序列号排序，服务器回包时带上这个序列号，前端根据序列号找到对应的占位消息并替换。这个方案虽然土，但在小程序受限的环境里足够稳定。

聊天功能里最绕不开的还有消息的可靠性。用户网络不稳定，发消息时断一下，消息就会丢失。我一开始想用 HTTP 轮询加本地缓存兜底，但发现小程序里 wx.request 的并发限制和超时机制让这事儿变得很麻烦。后来换成 WebSocket 后，干脆自己搞了个简单的确认机制：前端发消息时，先在本地存一份，同时给服务器发一个带唯一 ID 的消息包；服务器收到后回一个 ACK 包，带上同样的 ID；前端收到 ACK 就把本地缓存里那条消息的状态从“发送中”改成“已发送”。如果超时没收到 ACK，前端就自动重发，最多重试三次。这个机制虽然增加了网络开销，但用户至少能看到消息状态，知道是“发送中”还是“发送失败”，体验上比丢消息好太多。后来我在网上看到有人用类似方案，叫“可靠消息传输”，心里还有点得意，觉得自己没白折腾。

说到消息存储，又是个坑。小程序本地存储只有 10 MB，放几条文本消息还行，但用户聊天记录多了，图片和语音根本存不下。我最初的想法是只存最近 100 条消息到本地，其他从服务器拉取。但用户在聊天列表里上下滑动时，如果频繁请求历史消息，流量和速度都受不了。后来我想到一个折中方案：本地用 LRU 缓存，只保留最近 200 条消息和最近 10 个会话的索引；用户点击某个会话时，先显示本地缓存里的消息，同时异步从服务器拉取增量更新。服务器端我也做了优化，每次只返回用户上次拉取之后的新消息，外加分页接口让用户手动加载更早的历史。这样既避免了本地存储爆炸，又保证了初次加载的秒开体验。不过这个方案有个小问题：用户换设备登录时，本地缓存全没了，初次加载会有点慢。我只好在服务器端做了个“最近会话”的预加载，用户登录后立刻推送最近 5 个会话的摘要，让界面先有个骨架，再慢慢拉详细内容。

图片和语音消息的处理，比纯文本麻烦十倍。小程序里图片上传有大小限制，10 MB 封顶，但用户手机相册里随便一张照片就三四兆，多传几张就卡住了。我做了压缩处理：用户选图后，先用小程序自带的 `compressImage` 压到 500 KB 以内，再上传。语音更坑，小程序录音接口返回的是临时文件路径，有效期只有几十分钟，必须立刻上传到服务器。而且语音消息播放时，如果用户切到其他页面，播放器会突然中断。我只好在全局维护一个音频管理器，每次播放前检查是否有其他音频在播放，有就停掉旧的，再播放新的。这个设计后来被用户吐槽“听一段语音切出去回来就断了”，但在小程序架构下确实没有更好的办法。我妥协了：在语音消息旁边加了个“未读”标记，用户点开后标记消失，这样至少能感知哪些语音没听完。

最让我没想到的是，聊天功能里最核心的不是技术，而是体验细节。比如消息的发送时间显示，如果用户聊天很频繁，每句话都带上时间会很冗余。我参考了微信的做法：相邻消息间隔超过 5 分钟才显示时间，否则只显示第一条消息的时间。会话列表里的消息摘要也要处理得当：如果是一张图片，摘要显示“[图片]”，是语音就显示“[语音]”，而不是直接把文件路径怼上去。这些细节看似简单，但每条都要写判断逻辑，还要考虑国际化——有些用户的系统语言是英文，时间格式和中文不一样。我花了整整两天把时间格式化函数重写，用 dayjs 库统一处理，才把这块理顺。后期测试时发现，iOS 和 Android 上时间显示还有差异，iOS 的 24 小时制和 12 小时制表现不同，又得补兼容。

聊天功能上线后，用户反馈最多的问题集中在通知上。小程序的通知推送和原生 App 不一样，没法在用户未打开小程序时直接弹窗。我只能用订阅消息，但用户必须主动订阅才能收到通知，而且订阅后有效期只有一次。很多用户嫌麻烦不订阅，结果别人发了消息他也不知道。我试过用模板消息做补救，但微信对模板消息的使用频率有限制，发多了会被封。于是我搞了一个“消息中心”页面，把所有未读消息汇总展示，用户每次打开小程序先看到这个页面，再跳转到具体会话。虽然绕了一点，但至少不会漏消息。后来有同行告诉我，可以配合小程序的云开发做离线消息队列，但需要额外付费，用户量小的话不划算。我算了下成本，决定先不采用，等用户量上来了再说。

现在回头看这个项目，感触最深的是：开发聊天功能的技术难度其实不高，真正考验人的，是对细节的耐心和对用户行为的理解。WebSocket 连接管理、消息可靠性保证、本地存储策略、图片压缩、时间格式化……每一个环节单独拎出来都不难，但串在一起就成了系统工程。更关键的是，要接受小程序平台的限制，在有限的资源下做出最接近原生体验的方案。比如没办法真正后台运行，就用 onHide/onShow 模拟；没办法全局推送，就用订阅消息加消息中心兜底。这些妥协在完美主义者眼里可能很粗糙，但用户只关心消息能不能正常发、能不能及时收到。技术人的骄傲有时得让位给产品的务实。如果你也在做小程序聊天功能，我的建议是：先把最基础的发消息、收消息、消息状态显示跑通，再慢慢优化细节。别一上来就想着搞智能回复、表情包、红包功能，那些都是锦上添花，基础的通信链路稳定了，用户才会留下来使用。