微信小程序里嵌聊天功能，程序后端用Spring Boot加WebSocket，聊天这套组合拳我前后折腾过三个项目。程序踩过的聊天坑比代码行数还多，今天直接说点实在的程序。

先看最核心的聊天那行代码。Spring Boot里启用WebSocket，程序一个@EnableWebSocket注解加一个配置类就完事。聊天但真正让小程序跑起来，程序你得注意协议差异——小程序用的聊天是wx.connectSocket，它不走原生WebSocket那套握手逻辑。程序第一次联调时我盯着控制台报错看了半小时，聊天最后发现是程序请求头里少了Origin字段，小程序端压根不给你带这个。聊天

服务端配置别偷懒。程序我习惯写个WebSocketConfigurer，手动注册handler和拦截器。拦截器里做token校验，别信什么“前端已经验证过了”这种鬼话。小程序端每次重连都会带新的session，你必须在握手阶段就把用户身份钉死。用Spring的HandshakeInterceptor，在beforeHandshake里把userId塞进attributes，后面每个会话都能拿到。

真正的坑在心跳机制。小程序切后台，WebSocket连接说断就断，而且它不像浏览器那样自动重连。我第一版没做心跳，用户锁屏十分钟再回来，消息全丢。后来学乖了，服务端每30秒ping一次，客户端收到pong就重置计时器，三次没响应直接关连接。小程序端还得在onSocketClose里写重连逻辑，带指数退避，不然弱网环境下能把服务器打崩。

消息格式别用JSON乱塞。我见过有人把图片base64直接放消息体里，一条消息几MB，服务端内存直接爆掉。正确做法是消息里只存消息类型和文件ID，图片视频走对象存储，聊天记录里存URL。小程序端拿到消息先判断type，是图片就调wx.previewImage，是文本就直接渲染。这样数据库查询也快，列表页不用每次拉全量数据。

会话管理比想象中麻烦。一个用户开多个小程序窗口，每个窗口一个WebSocket连接，服务端得维护userId到Session的映射。用ConcurrentHashMap存，key是userId，value是Set<Session>。发消息时遍历这个Set，全推送过去。用户下线记得从Set里移除，不然僵尸连接越积越多，内存泄漏就这么来的。

最后说个性能细节。Spring Boot默认的Tomcat容器对WebSocket支持一般，高并发下建议换Undertow或者Netty。我压测过，Tomcat撑到500连接就开始丢包，换Undertow后轻松过2000。当然你要是业务量小，Tomcat也够用，别过度设计。

小程序端的坑更隐蔽。wx.connectSocket的url参数不能带中文，必须encodeURIComponent。还有每次发消息前检查readyState，不是OPEN状态就排队等onOpen回调。最坑的是小程序在iOS上对WebSocket内存限制很严，消息多了会闪退，所以服务端要控制单条消息大小，超过10KB就拆分。

调试工具也别迷信微信开发者工具。它模拟器里的WebSocket行为和真机差很多，我遇到过模拟器一切正常，真机死活连不上的情况。最后在服务端加了访问日志，看到真机请求根本没到服务器，才想起来是域名白名单没配——小程序后台必须配置socket合法域名，而且不能带端口号。

这套东西跑通之后，聊天延迟能控制在200ms以内，基本感觉不到卡顿。但记住，WebSocket只是管道，真正的业务逻辑还是得靠消息队列削峰。用户狂刷消息时，先写Redis再异步落库，别让数据库成为瓶颈。我吃过这个亏，上线第一天就被用户刷爆了MySQL连接池。