簡(jiǎn)介在前后端分離架構(gòu)中實(shí)時(shí)通信是構(gòu)建在線協(xié)作類應(yīng)用的核心技術(shù)。WebSocket作為全雙工長(zhǎng)連接協(xié)議憑借低延遲和雙向通信優(yōu)勢(shì)已成為白板協(xié)作、共享畫布、在線批注等場(chǎng)景的首選方案。本文從實(shí)時(shí)通信基礎(chǔ)原理出發(fā)講解如何利用SpringBoot后端與Vue前端搭建多人實(shí)時(shí)繪畫平臺(tái)涵蓋WebSocket連接管理、消息協(xié)議設(shè)計(jì)、Canvas矢量筆跡同步、歷史畫布恢復(fù)、斷線重連與心跳?；畹汝P(guān)鍵環(huán)節(jié)。通過實(shí)際項(xiàng)目案例展示從開發(fā)到Nginx部署的完整鏈路并總結(jié)常見問題與排查技巧幫助開發(fā)者快速掌握實(shí)時(shí)協(xié)作類應(yīng)用的工程化實(shí)現(xiàn)思路。 多人協(xié)作繪畫最怕什么畫著畫著別人看不到你的筆跡或者說一句話要等半秒才顯示那種體驗(yàn)基本就廢了。我最近在做一個(gè)基于SpringBootVueWebSocket的多人實(shí)時(shí)在線協(xié)作繪畫平臺(tái)今天把整套設(shè)計(jì)思路和源碼實(shí)現(xiàn)細(xì)節(jié)從頭到尾捋一遍。適合正在做實(shí)時(shí)交互類項(xiàng)目的同學(xué)參考尤其是前后端分離架構(gòu)下WebSocket的落地場(chǎng)景——用來做協(xié)作白板、共享畫布、在線批注之類的功能完全可以直接抄作業(yè)。這個(gè)項(xiàng)目本身不復(fù)雜核心就一句話用WebSocket把多個(gè)瀏覽器客戶端的繪畫事件實(shí)時(shí)同步到服務(wù)端再由服務(wù)端廣播給其他人。但真正寫起來你會(huì)發(fā)現(xiàn)連接管理、消息協(xié)議、畫布同步、斷線重連、心跳?；蠲恳粋€(gè)節(jié)點(diǎn)都有坑。我會(huì)把關(guān)鍵代碼、參數(shù)選擇、踩過的坑全部分享出來。1. 項(xiàng)目需求拆解與技術(shù)選型1.1 核心需求從“單人畫板”到“多人同步畫板”先看需求。單機(jī)版繪畫板很好做無非是Canvas監(jiān)聽鼠標(biāo)事件畫完之后生成base64圖片。但多人協(xié)作意味著兩個(gè)核心變化第一每個(gè)操作都是消息。畫了一筆不是一個(gè)純本地行為而是一次事件廣播。其他用戶收到后在自己的畫布上重放。所以必須有一個(gè)穩(wěn)定的實(shí)時(shí)通信通道。第二狀態(tài)要一致。新加入的人要能看到此前別人畫的所有內(nèi)容否則他打開頁面就是一片空白。因此還需要一個(gè)“歷史畫布數(shù)據(jù)”的恢復(fù)機(jī)制比如保存所有筆跡坐標(biāo)或者定期生成快照。基于這兩點(diǎn)我選型如下能力模塊技術(shù)方案選型理由后端基礎(chǔ)框架SpringBoot 2.7.x生態(tài)成熟WebSocket集成簡(jiǎn)單團(tuán)隊(duì)上手快前端框架Vue 3 Vite組合式API寫實(shí)時(shí)交互更清爽Vite開發(fā)調(diào)試體驗(yàn)好實(shí)時(shí)通信原生WebSocketSpring WebSocket模塊不引入STOMP是因?yàn)楸疚陌笀?chǎng)景只有“廣播”一種消息模式原生協(xié)議更輕量定制空間大數(shù)據(jù)庫MySQL存用戶和房間只需要房間維度的元信息不需要存儲(chǔ)全部筆跡降低復(fù)雜度畫布實(shí)現(xiàn)HTML5 Canvas 矢量筆跡數(shù)據(jù)直接傳base64圖片帶寬壓力大矢量坐標(biāo)重繪更平滑為什么不用輪詢或SSE輪詢延遲高SSE是單向的無法滿足雙向?qū)崟r(shí)通信。WebSocket在低延遲、雙向通信上都有天然優(yōu)勢(shì)。如果想深入對(duì)比可以看WebSocket是長(zhǎng)連接全雙工連接建立后不需要反復(fù)握手對(duì)高頻繪畫事件來說這是最合適的協(xié)議。1.2 項(xiàng)目結(jié)構(gòu)前后端分離模塊怎么劃分整個(gè)項(xiàng)目我保持了典型的前后端分離結(jié)構(gòu)collaborative-drawing/ ├── backend/ │ ├── src/main/java/com/drawing/ │ │ ├── config/ // WebSocket配置、跨域配置 │ │ ├── controller/ // 房間創(chuàng)建、用戶進(jìn)入等HTTP接口 │ │ ├── model/ // 消息實(shí)體、房間實(shí)體 │ │ ├── handler/ // WebSocket處理器 │ │ └── service/ // 房間管理服務(wù) │ └── src/main/resources/ └── frontend/ ├── src/ │ ├── api/ // HTTP接口封裝 │ ├── components/ // 畫布組件、顏色選擇器等 │ ├── views/ // 首頁、繪畫頁 │ ├── store/ // Pinia狀態(tài)管理 │ └── utils/ // WebSocket封裝這個(gè)結(jié)構(gòu)有幾個(gè)好處后端只需要管好“連接”和“轉(zhuǎn)發(fā)”具體的畫布邏輯全部放前端服務(wù)端不關(guān)心你的畫筆是什么顏色、粗度是多少它只負(fù)責(zé)把每個(gè)事件原封不動(dòng)地派發(fā)給房間內(nèi)其他人。這樣職責(zé)邊界非常clear后續(xù)如果要擴(kuò)展聊天、白板標(biāo)注等能力只需要加消息類型。2. 后端實(shí)時(shí)通信核心實(shí)現(xiàn)2.1 加入依賴與WebSocket配置SpringBoot引入WebSocket非常方便先在pom.xml加入依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency然后寫一個(gè)配置類注冊(cè)WebSocket端點(diǎn)Configuration public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(drawingHandler(), /draw) .setAllowedOrigins(*); } Bean public WebSocketHandler drawingHandler() { return new DrawingHandler(); } }這里要注意setAllowedOrigins(*)在開發(fā)環(huán)境確實(shí)方便但生產(chǎn)環(huán)境必須顯式指定域名否則會(huì)被跨域風(fēng)險(xiǎn)和安全掃描盯上。如果前端端口是5173那就寫setAllowedOrigins(http://localhost:5173)。2.2 消息協(xié)議設(shè)計(jì)一個(gè)JSON搞定所有事件多人協(xié)作繪畫需要同步的事件類型不多但設(shè)計(jì)協(xié)議時(shí)要有前瞻性。我定義了一個(gè)統(tǒng)一的消息模型public class Message { private String type; // 消息類型join, draw, clear, history, pong... private String roomId; // 房間ID private String userId; // 用戶ID private Object data; // 數(shù)據(jù)體可能是筆跡坐標(biāo)、清屏指令等 }前端發(fā)送的消息都是這樣一個(gè)結(jié)構(gòu)后端只做校驗(yàn)和轉(zhuǎn)發(fā)。data字段用Object接收再通過Jackson轉(zhuǎn)成對(duì)應(yīng)的對(duì)象這樣不同消息類型可以攜帶不同的數(shù)據(jù)體同時(shí)又不需要為每種消息寫一堆類。常見的消息類型如下消息類型方向data內(nèi)容join客戶端 → 服務(wù)端房間信息draw客戶端 → 服務(wù)端 → 其他客戶端筆跡點(diǎn)數(shù)組 [{x, y}, ...]clear客戶端 → 服務(wù)端 → 其他客戶端無history服務(wù)端 → 新加入客戶端歷史筆跡數(shù)據(jù)pong客戶端 → 服務(wù)端心跳回復(fù)draw消息中我傳的是“一段筆畫”的數(shù)據(jù)而不是單個(gè)點(diǎn)。這樣有幾個(gè)好處第一減少消息數(shù)量用戶鼠標(biāo)按下到抬起之間攢一批點(diǎn)一次性發(fā)送網(wǎng)絡(luò)壓力小很多第二接收端可以一次性重繪避免頻繁重繪導(dǎo)致的閃爍。2.3 連接管理與房間廣播核心處理器是DrawingHandler繼承TextWebSocketHandler重寫三個(gè)方法Component public class DrawingHandler extends TextWebSocketHandler { // 房間 - 該房間所有會(huì)話 private final MapString, ListWebSocketSession roomSessions new ConcurrentHashMap(); Override public void afterConnectionEstablished(WebSocketSession session) throws Exception { // 從URL參數(shù)中拿到roomId比如 ws://localhost:8080/draw?roomroom1userIduser1 String room session.getAttributes().get(roomId).toString(); roomSessions.computeIfAbsent(room, k - new CopyOnWriteArrayList()).add(session); } Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { // 解析JSON轉(zhuǎn)發(fā)給同房間其他人 } Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception { String room session.getAttributes().get(roomId).toString(); ListWebSocketSession sessions roomSessions.get(room); if (sessions ! null) { sessions.remove(session); } } }房間ID我從URL參數(shù)解析在握手?jǐn)r截器中放入session attributes。這樣每個(gè)連接進(jìn)來就能知道自己屬于哪個(gè)房間不用在消息里反復(fù)攜帶房間ID也方便定向廣播。廣播邏輯簡(jiǎn)單粗暴但有效private void broadcastToRoom(String roomId, String userId, String payload) { ListWebSocketSession sessions roomSessions.get(roomId); if (sessions null || sessions.isEmpty()) { return; } for (WebSocketSession s : sessions) { if (s.isOpen() !userId.equals(s.getAttributes().get(userId))) { s.sendMessage(new TextMessage(payload)); } } }這里注意要排除發(fā)送者自己否則前端的處理邏輯會(huì)重復(fù)畫兩次。前端自己繪制的筆跡由本地Canvas直接繪制不需要再走一遍網(wǎng)絡(luò)回包。2.4 歷史畫布恢復(fù)新用戶不白屏新用戶加入一個(gè)已經(jīng)畫了很多內(nèi)容的房間如果不做任何處理他只能看到之后產(chǎn)生的筆跡。我采用了一個(gè)簡(jiǎn)單的方案后端內(nèi)存中維護(hù)每個(gè)房間的“歷史筆跡列表”用戶加入時(shí)一次性推給他。private final MapString, ListObject roomHistory new ConcurrentHashMap(); // 在handleTextMessage中收到draw消息時(shí) ListObject history roomHistory.computeIfAbsent(roomId, k - new ArrayList()); history.add(drawData); // 在afterConnectionEstablished中發(fā)送history消息 session.sendMessage(new TextMessage(historyJson));這個(gè)方案適合教學(xué)項(xiàng)目和中小規(guī)模場(chǎng)景內(nèi)存里放一段時(shí)間內(nèi)的筆跡數(shù)量大了以后再做滑動(dòng)窗口比如只保留最近500條。更專業(yè)的做法是存Redis或者直接落庫但那樣IO成本高還需要考慮時(shí)序問題反而把項(xiàng)目搞復(fù)雜了。3. 前端繪畫交互與WebSocket集成3.1 Canvas畫筆實(shí)現(xiàn)從鼠標(biāo)事件到矢量坐標(biāo)前端我用了Vue 3組合式API Canvas 2D。畫筆邏輯很直接canvas idboard width800 height600/canvasconst canvas ref(null); const ctx ref(null); let drawing false; let currentPoints []; function onMouseDown(e) { drawing true; currentPoints []; const { x, y } getPos(e); ctx.value.beginPath(); ctx.value.moveTo(x, y); currentPoints.push({ x, y }); } function onMouseMove(e) { if (!drawing) return; const { x, y } getPos(e); ctx.value.lineTo(x, y); ctx.value.stroke(); currentPoints.push({ x, y }); } function onMouseUp(e) { if (!drawing) return; drawing false; // 把這一筆的坐標(biāo)數(shù)組發(fā)給服務(wù)端 ws.send(JSON.stringify({ type: draw, roomId: currentRoomId, userId: currentUserId, data: currentPoints })); currentPoints []; }getPos需要計(jì)算鼠標(biāo)相對(duì)于Canvas左上角的坐標(biāo)不能用e.clientX直接用因?yàn)镃anvas可能不在視口左上角function getPos(e) { const rect canvas.value.getBoundingClientRect(); return { x: e.clientX - rect.left, y: e.clientY - rect.top }; }這個(gè)過程有幾處容易出問題的地方stroke()每次調(diào)用都會(huì)從beginPath的位置重畫效率低一點(diǎn)但對(duì)實(shí)時(shí)繪畫影響不大簡(jiǎn)單直接最穩(wěn)妥。另外如果用高分辨率屏還需要處理Canvas的縮放比例否則畫出來是模糊的const dpr window.devicePixelRatio || 1; canvas.value.width width * dpr; canvas.value.height height * dpr; canvas.value.style.width width px; canvas.value.style.height height px; ctx.value.scale(dpr, dpr);這塊不處理在Retina屏上畫出來的線條就會(huì)發(fā)虛。我當(dāng)時(shí)排查了很久才發(fā)現(xiàn)是這個(gè)問題。3.2 遠(yuǎn)程筆跡重放收到數(shù)據(jù)怎么畫收到draw消息后前端需要把別人的筆跡畫出來。注意要從對(duì)方坐標(biāo)數(shù)組的第一個(gè)點(diǎn)開始連接function handleDraw(data) { const points data; if (points.length 0) return; ctx.value.beginPath(); ctx.value.moveTo(points[0].x, points[0].y); for (let i 1; i points.length; i) { ctx.value.lineTo(points[i].x, points[i].y); } ctx.value.stroke(); }有人會(huì)問為什么不用lineCap如果默認(rèn)因?yàn)镃anvas中stroke是整個(gè)路徑一次性處理的所以跨多個(gè)點(diǎn)的折線會(huì)自動(dòng)連接不會(huì)有鋸齒。還有一個(gè)細(xì)節(jié)畫筆顏色和粗細(xì)必須跟著消息一起傳。每個(gè)人可能選了不同的顏色如果不傳新用戶就會(huì)用默認(rèn)顏色畫別人的筆跡。我在draw消息的data里加了一個(gè)對(duì)象data: { points: currentPoints, color: currentColor, size: currentSize }后端把整個(gè)data原樣廣播前端重繪時(shí)先設(shè)置strokeStyle和lineWidth再畫路徑。這樣每個(gè)人的畫筆狀態(tài)就是獨(dú)立的。3.3 WebSocket封裝自動(dòng)重連與心跳?；钋岸薟ebSocket不能裸寫必須封裝一個(gè)帶重連機(jī)制的類。我在utils/ws.js里做了這樣的封裝let socket null; let retryCount 0; let heartBeatTimer null; export function connectWebSocket(roomId, userId, handlers) { const protocol location.protocol https: ? wss : ws; const url ${protocol}://${location.host}/draw?room${roomId}userId${userId}; socket new WebSocket(url); socket.onopen () { retryCount 0; startHeartBeat(); }; socket.onmessage (event) { const msg JSON.parse(event.data); if (msg.type history) { handlers.onHistory(msg.data); } else if (msg.type draw) { handlers.onDraw(msg.data); } else if (msg.type clear) { handlers.onClear(); } }; socket.onclose () { stopHeartBeat(); if (retryCount 5) { retryCount; setTimeout(() connectWebSocket(roomId, userId, handlers), 1000 * retryCount); } }; socket.onerror (err) { console.error(WebSocket error:, err); // 某些情況下error后會(huì)自動(dòng)close所以不用在這里重連 }; } function startHeartBeat() { heartBeatTimer setInterval(() { if (socket.readyState WebSocket.OPEN) { socket.send(JSON.stringify({ type: ping })); } }, 30000); }后端收到ping消息后簡(jiǎn)單回一個(gè)pong或者直接忽略因?yàn)閃ebSocket協(xié)議本身有心跳機(jī)制但瀏覽器端JS無法直接控制協(xié)議層的心跳報(bào)文所以應(yīng)用層心跳是必要的。如果不做心跳連接在一段時(shí)間空閑后會(huì)被Nginx或云服務(wù)商的網(wǎng)關(guān)斷開。我之前被這個(gè)問題坑過一次畫板放著不動(dòng)幾分鐘再畫就沒反應(yīng)了就是因?yàn)檫B接已被靜默斷開前端還渾然不知。加了心跳之后連接穩(wěn)定性顯著提升。斷線重連的間隔用退避策略第一次1秒第二次2秒最多5次避免短時(shí)間頻繁重連打爆服務(wù)端。斷線期間用戶畫的本地筆跡不會(huì)丟但無法同步給其他人這一點(diǎn)在UI上可以給個(gè)提示“連接已斷開正在重連”我當(dāng)時(shí)是加了一個(gè)狀態(tài)角標(biāo)。4. 原型系統(tǒng)集成與前后端部署實(shí)踐4.1 SpringBoot CORS與WebSocket攔截器細(xì)節(jié)前后端分離后HTTP接口會(huì)面臨跨域問題。SpringBoot的處理方式很常規(guī)Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(*); } }但WebSocket的握手請(qǐng)求不受這個(gè)CORS配置管控需要在WebSocket握手階段處理。在WebSocketConfig里調(diào)用setAllowedOrigins即可前面已經(jīng)提過。如果是Nginx反代還需要在Nginx配置中允許Upgrade相關(guān)的請(qǐng)求頭這個(gè)我們放到后面排查部分說。線程模型方面SpringBoot默認(rèn)內(nèi)嵌Tomcat會(huì)對(duì)WebSocket連接做阻塞式IO處理Tomcat 8.5以上版本已經(jīng)支持Java WebSocket 1.1的異步處理。我這里沒有做復(fù)雜的并發(fā)控制因?yàn)槊慷喂P跡的消息體就幾百字節(jié)單機(jī)幾百個(gè)并發(fā)連接完全沒問題。但如果要做集群部署就需要引入消息中間件進(jìn)行跨節(jié)點(diǎn)廣播了這就是另一個(gè)層面的架構(gòu)問題了。4.2 前端Vue組件化工具欄、顏色選擇器和畫布分離前端不能把所有邏輯塞在一個(gè)頁面里至少要拆成工具欄組件、畫布組件和連接狀態(tài)組件。我的頁面結(jié)構(gòu)如下DrawingBoard.vue ├── ToolBar.vue // 畫筆顏色、粗細(xì)、清除畫布按鈕 └── BoardCanvas.vue // Canvas畫布 鼠標(biāo)事件 重繪邏輯ToolBar中用Pinia來保存當(dāng)前顏色和粗細(xì)BoardCanvas讀取這些狀態(tài)工具欄上“清除”按鈕觸發(fā)一個(gè)clear消息前端收到后清空畫布同時(shí)后端也清空該房間的歷史筆跡防止別人加入時(shí)又看到已清除的內(nèi)容function clearBoard() { ctx.value.clearRect(0, 0, canvas.value.width, canvas.value.height); ws.send(JSON.stringify({ type: clear, roomId: currentRoomId, userId: currentUserId })); }后端收到clear后把對(duì)應(yīng)房間的歷史列表清空再向其他人廣播clear。顏色選擇器我用的是input typecolor勝在原生、零依賴。粗細(xì)滑塊用input typerange這兩個(gè)配合起來就能滿足基礎(chǔ)繪圖需求。如果想更專業(yè)可以上slider預(yù)設(shè)筆刷但核心邏輯不變。4.3 使用Nginx代理WebSocket的配置示例如果前端構(gòu)建后部署到Nginx后端單獨(dú)跑在8080端口那么Nginx配置需要把HTTP請(qǐng)求和WebSocket升級(jí)請(qǐng)求都代理到后端。這里給出完整的配置片段server { listen 80; server_name drawing.example.com; # 前端靜態(tài)資源 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端HTTP接口 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # WebSocket升級(jí) location /draw { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 3600s; proxy_send_timeout 3600s; } }關(guān)鍵就是proxy_set_header Upgrade $http_upgrade和Connection upgrade這兩行。沒有它們?yōu)g覽器握手請(qǐng)求會(huì)被Nginx當(dāng)作普通HTTP請(qǐng)求處理返回400或504。proxy_read_timeout默認(rèn)60秒如果不改大WebSocket長(zhǎng)時(shí)間空閑會(huì)被Nginx主動(dòng)斷開心跳可以部分解決但直接把超時(shí)調(diào)大更省心。4.4 從開發(fā)到生產(chǎn)Docker部署注意事項(xiàng)我習(xí)慣把后端和前端分別打Docker鏡像用docker-compose一鍵拉起。后端Dockerfile非常簡(jiǎn)單FROM maven:3.8-openjdk-11 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:11-jre-slim WORKDIR /app COPY --frombuild /app/target/drawing.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]前端Dockerfile更簡(jiǎn)單構(gòu)建完的靜態(tài)文件放到Nginx鏡像里FROM node:18 AS build WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx:stable-alpine COPY --frombuild /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80注意前端在構(gòu)建時(shí)要配置環(huán)境變量把VITE_WS_BASE指向ws://域名/draw不要寫死localhost。我在connectWebSocket里用location.host來動(dòng)態(tài)拼接這樣就可以直接適配不同域名不需要改代碼。5. 常見問題與排查技巧實(shí)錄5.1 連接建立后立即斷開狀態(tài)碼1006這是我在開發(fā)中遇到最多的問題。前端顯示W(wǎng)ebSocket連接失敗狀態(tài)碼1006表示連接異常關(guān)閉通常不是瀏覽器主動(dòng)關(guān)閉而是服務(wù)端或代理層把連接斷了。排查步驟先檢查后端日志看握手是否成功afterConnectionEstablished有沒有被調(diào)用。如果沒被調(diào)用檢查端點(diǎn)地址是否匹配客戶端請(qǐng)求的路徑與registry.addHandler中的路徑是否一致。如果后端有權(quán)限攔截或過濾器檢查是否把WebSocket握手請(qǐng)求攔掉了比如Shiro、Spring Security會(huì)默認(rèn)攔截所有請(qǐng)求。如果在Nginx后面檢查Upgrade和Connection配置。最后看端口是否被防火墻攔截netstat -an | grep 8080看一下監(jiān)聽狀態(tài)。有一個(gè)容易踩的坑在SpringBoot中如果同時(shí)引入了spring-boot-starter-securityWebSocket握手會(huì)默認(rèn)走認(rèn)證流程導(dǎo)致401。解決方案是在Security配置中放行WebSocket端點(diǎn)http.authorizeRequests() .antMatchers(/draw, /api/**).permitAll() ...或者干脆在WebSocket握手?jǐn)r截器中做自定義認(rèn)證用Token參數(shù)校驗(yàn)身份。5.2 多人同時(shí)畫畫面互相覆蓋或者錯(cuò)亂這個(gè)問題一般不是網(wǎng)絡(luò)問題而是畫筆狀態(tài)沒有隔離。比如用戶A設(shè)置了紅色畫筆他發(fā)的消息里帶了color但用戶B收到后沒有先設(shè)置strokeStyle就直接畫導(dǎo)致紅色畫完后再畫自己的黑色結(jié)果兩個(gè)人的筆跡顏色混在一起。解決思路遠(yuǎn)端重繪時(shí)每次都重新設(shè)置顏色和粗細(xì)不要依賴上一次的狀態(tài)。同時(shí)在draw消息的數(shù)據(jù)體里把color和size放在points旁邊。一次完整的消息結(jié)構(gòu)如下{ type: draw, roomId: room1, userId: user1, data: { points: [{x: 10, y: 20}, {x: 11, y: 22}], color: #ff0000, size: 3 } }5.3 歷史消息推送時(shí)機(jī)問題新用戶加入時(shí)后端在afterConnectionEstablished里發(fā)送history消息。但有一個(gè)并發(fā)問題如果用戶加入的瞬間正好有人正在畫一筆那這一筆可能已經(jīng)寫入歷史列表而前端還沒收到history消息就收到了draw消息導(dǎo)致順序錯(cuò)亂——先畫了最新一筆然后又被history整個(gè)重繪覆蓋最新一筆反而不見了。我的解決辦法是前端收到history后先清空畫布再執(zhí)行歷史重繪在連接建立之后的一小段時(shí)間內(nèi)收到的draw消息先緩存起來等history處理完再批量執(zhí)行。也可以更簡(jiǎn)單地在后端廣播時(shí)加一個(gè)序號(hào)前端按序號(hào)排序但這會(huì)增加協(xié)議復(fù)雜度。對(duì)Demo項(xiàng)目來說用“緩存后處理”的方式足夠了。let pendingDraws []; socket.onmessage (event) { const msg JSON.parse(event.data); if (msg.type history) { historyLoaded true; clearCanvas(); redrawHistory(msg.data); pendingDraws.forEach(draw handleDraw(draw)); pendingDraws []; } else if (msg.type draw) { if (!historyLoaded) { pendingDraws.push(msg.data); } else { handleDraw(msg.data); } } };5.4 線程安全與內(nèi)存泄漏roomSessions和roomHistory我用了ConcurrentHashMap內(nèi)層的List用了CopyOnWriteArrayList保證并發(fā)修改和遍歷不沖突。但這只是單機(jī)場(chǎng)景。如果連接不關(guān)閉歷史列表會(huì)無限增長(zhǎng)形成內(nèi)存泄漏。因此我簡(jiǎn)單加了一個(gè)上限if (history.size() 500) { history.subList(0, history.size() - 500).clear(); }這種方式很粗暴卻能保證內(nèi)存不會(huì)無限膨脹。你也可以把歷史數(shù)據(jù)持久化到Redis或數(shù)據(jù)庫每次新用戶加入時(shí)從數(shù)據(jù)庫讀取。那個(gè)方案會(huì)重很多但對(duì)團(tuán)隊(duì)協(xié)作產(chǎn)品來說更靠譜。5.5 白屏問題一定檢查Canvas寬高設(shè)置很多新手會(huì)把Canvas的寬高寫死在HTML標(biāo)簽里比如canvas width800 height600/canvas這在靜態(tài)頁面沒問題但如果Canvas放在一個(gè)響應(yīng)式布局中或者在對(duì)話框/彈窗里顯示實(shí)際顯示尺寸往往會(huì)被CSS縮放而內(nèi)部繪圖分辨率和顯示尺寸不匹配畫出來的線會(huì)偏移和模糊。最穩(wěn)妥做法是在mounted里通過容器尺寸動(dòng)態(tài)設(shè)置Canvas的width和height同時(shí)處理devicePixelRatio然后監(jiān)聽窗口大小變化重設(shè)尺寸并重繪歷史數(shù)據(jù)。這部分的代碼比較多但在協(xié)作繪畫項(xiàng)目中屬于基本功。5.6 消息體過大導(dǎo)致連接卡死如果鼠標(biāo)快速移動(dòng)mouseMove事件觸發(fā)頻率會(huì)很高。我試過把每個(gè)點(diǎn)都實(shí)時(shí)發(fā)送結(jié)果消息隊(duì)列積壓畫布卡成PPT。后來改為“一筆一筆發(fā)”只在鼠標(biāo)抬起時(shí)發(fā)送整段筆跡。這樣一個(gè)筆畫最多十幾個(gè)或幾十個(gè)點(diǎn)消息體幾十字節(jié)到幾百字節(jié)完全在可接受范圍。如果要更精細(xì)的實(shí)時(shí)效果比如看到對(duì)方毛筆筆鋒的實(shí)時(shí)軌跡可以增加定時(shí)批量發(fā)送每50ms發(fā)送一次增量點(diǎn)這樣既有實(shí)時(shí)性又不會(huì)太頻繁。我的項(xiàng)目沒有做這么細(xì)因?yàn)橐还P一畫的方式對(duì)普通白板場(chǎng)景已經(jīng)夠了。6. 項(xiàng)目擴(kuò)展與個(gè)人經(jīng)驗(yàn)總結(jié)這個(gè)平臺(tái)的骨架搭建起來之后后續(xù)擴(kuò)展空間非常大。我整理了幾個(gè)可以繼續(xù)深入的方向更多工具類型矩形、圓形、直線、文字輸入等等只需要擴(kuò)展消息類型的data結(jié)構(gòu)。實(shí)時(shí)在線狀態(tài)通過join和leave消息維護(hù)用戶列表顯示當(dāng)前房間有哪些人。Undo/Redo后端維護(hù)操作棧廣播undo指令接收端回退一筆。筆跡同步優(yōu)化用差分同步算法只發(fā)送變化區(qū)域或者用二進(jìn)制協(xié)議protobuf替代JSON提升大數(shù)據(jù)量場(chǎng)景下的性能。服務(wù)端集群化多個(gè)實(shí)例間通過Redis Pub/Sub或MQ做消息轉(zhuǎn)發(fā)保證跨實(shí)例房間廣播的一致性。根據(jù)我個(gè)人幾次做實(shí)時(shí)協(xié)作項(xiàng)目的體會(huì)WebSocket本身并不難難的是消息協(xié)議設(shè)計(jì)和異常恢復(fù)機(jī)制。這個(gè)項(xiàng)目里我踩得最深的坑有兩個(gè)一個(gè)是Nginx代理配置缺失導(dǎo)致外網(wǎng)連接不穩(wěn)定另一個(gè)是歷史消息和實(shí)時(shí)消息的順序問題。如果你也打算寫類似功能建議先從這兩個(gè)點(diǎn)入手設(shè)計(jì)能少走不少彎路——先把一次典型的多人會(huì)話流程畫清楚再寫代碼后面會(huì)省很多事。本文還有配套的精品資源點(diǎn)擊獲取