背景痛点:轮询时代的“假实时”
做客服系统最怕什么?不是用户骂你,而是“消息已读不回”——其实根本没收到。
传统方案里,前端每 3 秒轮询一次接口,看似保险,实则一地鸡毛:
- 延迟:最坏情况下消息要等 3 秒才出现,用户体验像写信。
- 流量:一次轮询至少 500 B,日活 1 w 就是 1.2 GB 的纯浪费。
- 顺序:并发请求返回顺序不确定,“客服已输入”提示可能闪来闪去。
- 雪崩:高峰期接口 RT 飙到 800 ms,浏览器并发打满,页面直接卡死。
一句话:轮询不是“实时”,是“实时抽奖”。
技术选型:WebSocket 不是银弹,但最合身
| 方案 | 延迟 | 兼容性 | 服务器开销 | 结论 |
|---|---|---|---|---|
| 短轮询 | 1~3 s | 100 % | 高 | 快速原型可用 |
| 长轮询 | 0.3~1 s | 100 % | 中 | 防火墙穿透好,仍浪费握手 |
| SSE | <0.2 s | 除 IE | 低 | 服务端推送简单,仅支持文本 |
| WebSocket | <0.1 s | 97 % | 最低 | 全双工,最贴合客服场景 |
本地 loopback 测试(Mac M2 + Chrome 116):
- 短轮询平均 1100 ms
- 长轮询 320 ms
- SSE 85 ms
- WebSocket 18 ms
数据摆在这,老板再让“兼容 IE”你就把表格甩给他。
核心实现:把聊天抽象成 useChatHook
1. 类型先写死,别等联调再哭
// types/chat.d.ts export interface Message { id: string; // 雪花算法或 UUID role: 'user' | 'agent' | 'bot'; content: string; timestamp: number; status: 'sending' | 'sent' | 'ack' | 'fail'; }2. Hook 骨架:连接、重连、发消息全包圆
// composables/useChat.ts import { ref, reactive, nextTick } from 'vue' import { useWebSocket } from '@vueuse/core' export function useChat(url: string, token: string) { const list = ref<Message[]>([]) const pending = ref<Map<string, Message>>(new Map()) const { status, data, send, open, close } = useWebSocket(url, { autoReconnect: { retries: 5, delay: 1000, onFailed() { alert('网络开小差,请刷新页面') } }, protocols: ['chat', token] }) // 发消息自带本地幂等 ID const push = (content: string) => { const const msg: Message = { id: self.crypto.randomUUID(), role: 'user', content, timestamp: Date.now(), status: 'sending' } list.value.push(msg) pending.value.set(msg.id, msg) send(JSON.stringify(msg)) } // 收到远端回包 watch(data, raw => { const msg: Message = JSON.parse(raw) const cached = pending.value.get(msg.id) if (cached) { cached.status = 'ack' pending.value.delete(msg.id) } else { // 客服端新消息 list.value.push(msg) } }) return { list, push, status } }3. 幂等去重:MessageID 是钥匙
服务端可能重复推送(重发补偿),前端必须在 reducer 里过滤:
const uniqueList = computed(() => { const seen = new Set<string>() return list.value.filter(m => { if (seen.has(m.id)) return false seen.add(m.id) return true }) })性能优化:长列表不卡才是真爱
1. 虚拟滚动:只渲染可视区
<template> <div ref="viewport" class="h-96 overflow-auto"> <div :style="spacerStyle"> <div v-for="m in renderList" :key="m.id" class="msg-row"> <MsgBubble :msg="m" /> </div> </div> </div> </template> <script setup lang="ts"> import { useVirtualList } from '@vueuse/core' const { list } = useChat(...) const { containerProps, wrapperProps, scrollTo } = useVirtualList(list, { itemHeight: 72, // 预估单行高度 overscan: 5 }) </script>2. Intersection Observer 自动滚动到底
const anchor = ref<HTMLElement>() useIntersectionObserver(anchor, ([{ isIntersecting }]) => { if (isIntersecting) scrollTo(list.value.length - 1) })3. 状态快照:刷新也不丢
watchThrottled( list, () => { localStorage.setItem('chat_snapshot', JSON.stringify(list.value)) }, { throttle: 1000, deep: true } ) onMounted(() => { const snap = localStorage.getItem('chat_snapshot') if (snap) list.value = JSON.parse(snap) })注意 throttle 与 debounce区别:
- throttle:固定间隔执行,适合高频采样。
- debounce:尾调用触发,适合输入框。
这里选 throttle,保证每秒至少存一次,异常刷新最多丢 1 s 消息。
避坑指南:那些线上才遇到的怪毛病
1. 跨域:Nginx 一把梭
location /ws { proxy_pass http://chat-svc:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Origin ""; }前端new WebSocket('wss://yourdomain/ws')即可,不用纠结 Cookie。
2. 大模型流式响应:别每次都 setState
后端 SSE 转 WebSocket 分段推送,前端把 chunk 拼接到同一条 message.content,框架层再做一次细粒度 debounce(50 ms)刷新视图,避免 Vue 的响应式疯狂计算 Diff。
let buffer = '' const renderDebounce = debounce((msg: Message) => { const target = list.value.find(m => m.id === msg.id) if (target) target.content = buffer }, 50) watch(data, chunk => { buffer += chunk renderDebounce(msg) })安全考量:别让客服成 XSS 入口
- JWT 鉴权:握手阶段把 token 放到 WebSocket 子协议头,后端验证失败直接
close(1008)。 - 内容净化:
- 用户输入用
DOMPurify.sanitize()过一遍再落库。 - AI 返回的 Markdown 先转 HTML 再净化,最后交由
v-html。
- 用户输入用
- 指令白名单:禁止
<script>、<iframe>、<object>,事件事件一律转义。
完整流程回顾
- 用户输入 → 本地幂等 ID → WebSocket 发送
- 服务端 ACK → 前端更新状态 → 虚拟滚动自动定位
- 客服 or 机器人回复 → 去重 → 流式渲染 → 本地快照
- 异常断网 → Hook 自动重连 → 继续上一步上下文
结论与开放思考
整套方案跑在阿里云 2 vCPU 的小水管上,压测 500 并发,CPU 占用 38 %,内存 220 MB,消息延迟 P99 低于 120 ms,已撑住公司 30 % 的日活客服流量。
但线上永远有新坑:
“如何设计离线消息同步策略?”
当用户关掉网页、APP 杀进程,再到另一端登录,未读消息该怎么聚合、去重、排序?
欢迎评论区一起头脑风暴,也许你的思路就是下一篇 PR 的主角。