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