1. 为什么微信小程序需要自定义SSE方案微信小程序的网络通信API在设计上做了很多限制这给需要实时数据推送的场景带来了挑战。官方提供的wx.request虽然功能强大但并不直接支持标准的Server-Sent EventsSSE协议。我去年在开发一个实时股票行情小程序时就遇到了这个问题——服务端已经实现了SSE推送但小程序端却无法直接使用。SSE协议最大的特点是单向持续连接服务端可以随时推送数据而客户端只需要建立一次连接。这与WebSocket不同SSE更适用于服务端主导的推送场景比如新闻推送、实时监控。微信小程序虽然提供了WebSocket支持但在某些场景下SSE才是更合适的选择更简单的服务端实现自动重连机制轻量级的消息格式更好的浏览器兼容性虽然小程序用不到这点经过多次尝试我发现wx.request有一个隐藏特性——enableChunked。当这个参数设为true时请求会以分块方式接收数据这正是实现SSE的基础。下面这段代码展示了最基本的开启方式wx.request({ url: your_sse_endpoint, enableChunked: true, onChunkReceived: (res) { console.log(收到数据分块:, res.data) } })但仅仅这样还远远不够。在实际项目中我遇到了三个主要问题数据分片可能截断UTF-8字符、SSE协议需要特殊解析、以及异常情况下的内存管理。接下来我们就深入探讨如何解决这些问题。2. 核心实现从字节流到完整消息2.1 处理分块数据与字符截断当enableChunked开启后数据会以ArrayBuffer的形式分块到达。第一个要解决的问题是分块可能正好截断了一个UTF-8字符。比如一个4字节的中文字符前两个字节在一个分块后两个字节在下一个分块。我设计了一个缓冲机制来解决这个问题。核心思路是维护一个全局的MaplastArrayBuffer来存储每个连接未处理完的字节每次收到新数据时先检查是否有上次未处理完的数据如果有就将新旧数据拼接后再处理处理过程中识别不完整的UTF-8字符并暂存这里有个关键点如何识别UTF-8字符的边界UTF-8字符的第一个字节的高位会告诉我们这个字符总共占多少字节0xxxxxxx单字节字符110xxxxx双字节字符1110xxxx三字节字符11110xxx四字节字符对应的处理代码如下function arrayBufferToString(arr, uid) { if (lastArrayBuffer.has(uid)) { // 合并新旧数据 const combined new Uint8Array([ ...new Uint8Array(lastArrayBuffer.get(uid)), ...new Uint8Array(arr) ]); arr combined.buffer; lastArrayBuffer.delete(uid); } const view new Uint8Array(arr); let result ; let i 0; while (i view.length) { const byte view[i]; if ((byte 0x80) 0) { // 单字节字符 result String.fromCharCode(byte); i; } else { // 多字节字符 let byteLength; if ((byte 0xE0) 0xC0) byteLength 2; else if ((byte 0xF0) 0xE0) byteLength 3; else if ((byte 0xF8) 0xF0) byteLength 4; else { // 非法UTF-8序列 result String.fromCharCode(byte); i; continue; } // 检查是否足够字节 if (i byteLength view.length) { // 不完整字符保存剩余字节 const remaining view.slice(i); const buffer new ArrayBuffer(remaining.length); new Uint8Array(buffer).set(remaining); lastArrayBuffer.set(uid, buffer); break; } // 处理完整字符 let codePoint 0; for (let j 0; j byteLength; j) { codePoint (codePoint 6) | (view[i j] 0x3F); } result String.fromCodePoint(codePoint); i byteLength; } } return result; }2.2 SSE协议解析SSE的数据格式相对简单每条消息以data:开头以两个换行符结束。但实际项目中会遇到一些复杂情况多条消息可能在一个分块中同时到达一条消息可能被分割到多个分块中消息中可能包含JSON数据我使用正则表达式来提取消息内容同时引入了一个LegacyMessage机制来处理不完整的消息const parseSSEData (str) { // 匹配data:开头直到下一个data:或结尾 const regex /data:([\s\S]*?)(?\n\s*data:|$)/g; return [...str.matchAll(regex)].map(match match[0].trim()); }; const LegacyMessage new Map(); function processChunk(uid, str, callback) { const prefix LegacyMessage.get(uid) || ; const fullStr prefix str; const messages parseSSEData(fullStr); if (messages.length 0) { LegacyMessage.set(uid, fullStr); return; } LegacyMessage.delete(uid); // 处理完整消息 for (let i 0; i messages.length - 1; i) { try { const data JSON.parse(messages[i].slice(5)); callback(data); } catch (e) { console.error(消息解析失败:, e); } } // 处理最后一条可能不完整的消息 const last messages[messages.length - 1]; try { const data JSON.parse(last.slice(5)); callback(data); } catch (e) { LegacyMessage.set(uid, last); } }3. 工业级封装与异常处理3.1 完整的SSE客户端封装基于前面的基础我们可以封装一个健壮的SSE客户端。这个封装需要解决几个实际问题请求生命周期管理内存泄漏预防错误处理多实例隔离下面是核心封装代码const sseClients new Map(); export function createSSEClient(options) { const { url, data, onMessage, onError, onComplete } options; const uid Math.random().toString(36).substring(2, 9); const cleanup () { LegacyMessage.delete(uid); lastArrayBuffer.delete(uid); sseClients.delete(uid); }; const handleChunk (res) { try { const str arrayBufferToString(res.data, uid); if (str ) return; processChunk(uid, str, (data) { onMessage?.(data); }); } catch (err) { onError?.(err); } }; const requestTask wx.request({ url: ${BASE_URL}${url}, method: POST, enableChunked: true, data, header: { Content-Type: application/json }, complete: (res) { cleanup(); onComplete?.(res); } }); requestTask.onChunkReceived(handleChunk); const client { abort: () { requestTask.offChunkReceived(handleChunk); requestTask.abort(); cleanup(); } }; sseClients.set(uid, client); return client; }3.2 常见问题与解决方案在实际使用中我遇到了几个典型问题问题1内存泄漏表现长时间运行后小程序卡顿原因未清理的缓存数据和事件监听解决方案在complete和abort时清理所有缓存使用WeakMap替代Map但小程序环境不支持问题2乱码表现偶尔出现乱码字符原因UTF-8字符被错误拼接解决方案严格遵循UTF-8编码规范增加字节序列验证问题3消息丢失表现部分消息未被触发原因网络波动导致分块异常解决方案实现消息完整性检查增加重试机制针对这些问题我对核心代码做了加固function validateUTF8(bytes) { for (let i 0; i bytes.length; ) { const byte bytes[i]; let byteLength; if ((byte 0x80) 0) { byteLength 1; } else if ((byte 0xE0) 0xC0) { byteLength 2; } else if ((byte 0xF0) 0xE0) { byteLength 3; } else if ((byte 0xF8) 0xF0) { byteLength 4; } else { return false; } if (i byteLength bytes.length) return false; for (let j 1; j byteLength; j) { if ((bytes[i j] 0xC0) ! 0x80) { return false; } } i byteLength; } return true; }4. 实战应用与性能优化4.1 在真实项目中的使用在我负责的物流追踪小程序中这个SSE方案发挥了重要作用。司机端需要实时接收订单状态更新服务端通过SSE推送以下数据新订单分配订单状态变更系统通知位置更新使用方式非常简单const sseClient createSSEClient({ url: /driver/updates, data: { driverId: 12345 }, onMessage: (data) { switch (data.type) { case NEW_ORDER: showNewOrderAlert(data.order); break; case STATUS_UPDATE: updateOrderStatus(data.orderId, data.status); break; } }, onError: (err) { showToast(连接异常正在重试...); } }); // 当页面卸载时 onUnload() { sseClient.abort(); }4.2 性能优化建议经过多个项目的实践我总结出以下优化建议心跳机制服务端应定期发送心跳消息如每30秒一次客户端检测到超时后自动重连流量控制对于高频更新场景如实时位置建议在服务端做节流差异化更新只推送变化的数据字段减少传输量优先级处理对重要消息如支付成功和普通消息如状态更新做区分处理本地缓存对历史消息做本地缓存提升用户体验心跳检测的实现示例let lastMessageTime Date.now(); const checkHeartbeat () { const now Date.now(); if (now - lastMessageTime 40000) { // 40秒无消息 reconnect(); } }; const heartbeatTimer setInterval(checkHeartbeat, 5000); // 收到消息时更新最后时间 onMessage: (data) { lastMessageTime Date.now(); // ...处理消息 } // 清理时 onComplete: () { clearInterval(heartbeatTimer); }5. 替代方案对比与选择建议虽然本文重点介绍了基于wx.request的SSE实现但微信小程序还有其他实时通信方案各有优缺点WebSocket优点官方支持双向通信缺点实现复杂需要维护连接状态云开发数据库监听优点无需自建服务简单易用缺点依赖微信云开发有功能限制定时轮询优点实现简单缺点实时性差资源消耗大选择建议简单场景优先考虑云开发数据库监听服务端主导的推送使用本文的SSE方案需要双向通信使用WebSocket低频更新定时轮询可能更简单在最近的一个电商项目中我们混合使用了这些方案商品库存变化使用SSE服务端推送聊天功能使用WebSocket需要双向通信用户信息更新使用云开发监听这种混合方案既保证了实时性又控制了开发复杂度。