Excalidraw会话超时机制设计：安全保障-育师

Excalidraw 会话超时与心跳机制设计：构建安全可靠的协作边界

在远程办公和分布式团队协作日益成为常态的今天，像 Excalidraw 这样轻量、直观且支持实时协同的在线白板工具，正逐渐成为产品设计、技术讨论乃至教学演示中的核心生产力平台。其手绘风格带来的亲和力，配合低延迟的同步能力，让抽象思维得以快速可视化。但随之而来的问题也愈发突出：当多个用户共享一个画布时，如何确保长时间未操作的会话不会变成安全隐患？又该如何精准判断谁“还在场”，谁已经悄然离开？

这些问题背后，其实指向同一个系统级挑战——会话生命周期管理。而其中最关键的两个技术支柱，正是会话超时机制与心跳检测机制。它们不像绘图引擎或AI生成功能那样引人注目，却如同空气一般不可或缺：一旦失效，整个协作环境的安全性与稳定性将迅速崩塌。

从一次“忘记关闭浏览器”说起

设想这样一个场景：你在公司会议室用公共电脑打开一个 Excalidraw 协作链接，绘制完架构图后匆匆离开，忘了关闭标签页。此时，你的会话仍通过 WebSocket 保持连接，身份凭证有效，画布数据缓存在内存中。如果系统没有任何限制，这个“幽灵会话”可能持续数小时甚至更久。

这不仅浪费服务器资源（每个连接都占用内存、事件监听器和 Redis 缓存），更危险的是——任何人只要接触到这台电脑，就能继续操作该画布，查看敏感信息，甚至冒名修改内容。对于涉及系统设计、商业策略的协作场景而言，这是不可接受的风险。

因此，必须有一种机制，在用户真实离场后及时收场。这就是会话超时存在的根本意义：它不是为了打断工作流，而是为了在无人看管时自动上锁。

超时机制的本质：一场关于“活跃”的定义战

表面上看，会话超时只是一个倒计时问题：“15分钟无操作就断开”。但深入实现就会发现，关键在于——什么叫“操作”？

在 Excalidraw 中，“操作”远不止点击或绘图。鼠标移动、缩放视图、切换工具、输入文本、拖动元素……这些都应该被视为活跃信号。但如果把所有 DOM 事件都上报给服务端，显然会造成不必要的网络开销。

于是我们采用一种分层策略：

前端聚合事件：客户端监听一系列 UI 交互事件（mousemove,touchstart,keydown,pointerdown等），但不立即发送。而是设置一个防抖定时器（如 2 秒），避免频繁触发。
统一上报活动：当检测到有效交互时，向服务端发送一条轻量级user_activity消息，表示“我还活着”。
服务端重置计时器：收到消息后，清空当前会话的超时定时器，并重新开始计时。

这种设计既保证了灵敏度，又控制了通信频率。更重要的是，它可以灵活扩展——比如未来支持语音标注功能时，语音输入也可以作为“活动”信号纳入判断逻辑。

// 客户端：聚合用户行为并触发 activity 上报 let activityTimer; function recordUserActivity() { clearTimeout(activityTimer); socket.emit('user_activity'); // 告知服务端有操作 activityTimer = setTimeout(() => {}, 2000); // 防抖 } // 绑定常见交互事件 document.addEventListener('mousemove', recordUserActivity); document.addEventListener('keydown', recordUserActivity); document.addEventListener('pointerdown', recordUserActivity);

与此同时，服务端为每个会话维护一个可刷新的定时器。一旦超时触发，立刻执行清理流程：

const SESSION_TIMEOUT_MS = 15 * 60 * 1000; function setupSessionTimeout(sessionId, socket, cleanupCallback) { let timer = setTimeout(() => { console.log(`[Timeout] Session ${sessionId} expired`); socket.emit('session_timeout_imminent', { seconds: 0 }); socket.disconnect(true); cleanupCallback(sessionId); }, SESSION_TIMEOUT_MS); return { refresh: () => { clearTimeout(timer); timer = setTimeout(() => { /* same logic */ }, SESSION_TIMEOUT_MS); }, destroy: () => clearTimeout(timer) }; }

这套模式看似简单，但在高并发环境下极具实用性。例如使用Map或外部缓存（Redis）存储控制器实例，即可轻松实现集群间状态同步。

心跳机制：不只是“我还活着”，更是“我还能干活”

如果说会话超时关注的是“有没有人在用”，那么心跳机制关注的就是“连接本身是否可靠”。

WebSocket 虽然提供了全双工通信能力，但网络是脆弱的。Wi-Fi 切换、手机休眠、NAT 超时、代理中断……这些都会导致连接无声断开。而操作系统底层的 TCP Keep-Alive 通常周期较长（默认 2 小时），无法满足实时协作对状态感知的精度要求。

因此，应用层的心跳机制必不可少。

Excalidraw 的做法是引入标准的ping/pong协议：

客户端每 30 秒主动发送一次ping消息；
服务端收到后立即回复pong，并更新该客户端的最后活跃时间戳；
若连续 3 个周期未收到ping（即 90 秒），则判定为离线。

这个机制看似冗余于前面的user_activity，实则职责分明：

机制	触发条件	主要目的
`user_activity`	用户交互	判断“是否仍在使用”
`ping/pong`	定时发送	判断“连接是否可用”

两者结合，才能完整刻画用户的在线状态。例如，某用户正在阅读画布（无操作），但网络突然中断。此时虽然没有user_activity，但由于缺少ping，系统仍能快速识别异常并通知其他协作者：“A 已断开”。

// 服务端：基于心跳判断连接健康度 io.on('connection', (socket) => { let lastPingTime = Date.now(); const HEARTBEAT_TOLERANCE = 3 * 30000; // 90秒容忍窗口 const monitor = setInterval(() => { if (Date.now() - lastPingTime > HEARTBEAT_TOLERANCE) { console.log(`[Heartbeat] Client ${socket.id} unresponsive`); socket.broadcast.emit('user_disconnected', { userId: socket.id }); cleanupSession(socket.id); clearInterval(monitor); socket.disconnect(); } }, 15000); socket.on('ping', () => { lastPingTime = Date.now(); socket.emit('pong', { timestamp: Date.now() }); }); socket.on('disconnect', () => { clearInterval(monitor); }); });

值得注意的是，心跳间隔不宜过短。30 秒是一个经过权衡的选择：既能较快发现问题，又不至于产生显著流量负担（平均每用户每天约 2.8KB 心跳数据）。对于移动端设备，还可根据网络类型动态调整（Wi-Fi 下 30 秒，蜂窝网下延长至 60 秒），以节省电量与带宽。

实际部署中的工程考量：安全与体验的平衡术

再精巧的技术设计，也需要落地到真实场景中接受考验。以下是我们在集成这两套机制时总结出的一些关键实践。

1. 分级超时策略：不是所有人都该被同等对待

默认 15 分钟的超时时间适用于大多数编辑者，但对于只读用户（viewer），过于频繁的断连反而影响体验。因此建议引入角色区分：

编辑者（Editor）：严格模式，15 分钟无操作即超时；
查看者（Viewer）：宽松模式，允许 60 分钟静默浏览；
公开分享链接：最短 5 分钟，防止滥用。

这种细粒度控制可通过 JWT Token 中携带权限信息来实现：

{ "sessionId": "abc123", "role": "viewer", "exp": 1735689600 }

服务端解析 token 后，动态设置不同的超时阈值。

2. 渐进式提醒：别让用户莫名其妙掉线

直接断开是最粗暴的做法。更好的方式是提供缓冲期：

超时前 2 分钟，前端弹出提示：“您的会话将在 2 分钟后关闭，是否继续？”
提供“保持在线”按钮，点击后向服务端发送续期请求；
续期成功，计时器重置，用户体验无缝延续。

这种方式既保障了安全底线，又体现了对用户注意力的尊重。

3. 断线不丢图：临时数据也要有尊严

即使会话超时，也不意味着一切归零。合理的做法是：

在断开前尝试保存最后一次画布快照到持久化存储；
设置 TTL（如 24 小时），允许用户重新加入时恢复最近状态；
对于启用了自动保存的项目，直接关联到对应文档版本。

这样即使误操作退出，也不会造成实质性损失。

4. 监控与审计：让每一次超时都有迹可循

所有超时事件应记录日志，包含：

会话 ID、用户标识（匿名/登录）、IP 地址；
最后一次活动时间、断开原因（主动退出 / 超时 / 心跳失败）；
是否触发了数据清理或归档动作。

这些数据不仅能用于故障排查，还能支撑合规需求（如 GDPR 的访问日志留存要求）。

架构整合：它们在系统中扮演什么角色？

在典型的 Excalidraw 部署架构中，这两个机制贯穿前后端协同链路：

graph LR A[客户端] -->|WebSocket| B[Node.js + Socket.IO] B --> C[Redis] B --> D[数据库] subgraph "核心逻辑" B -- 维护会话状态 --> E[超时控制器] B -- 检测连接健康 --> F[心跳监视器] end E -->|超时触发| G[清理缓存 & 广播离线] F -->|失联判定| G G --> H[通知其他协作者] E -->|可选| I[保存画布快照]

可以看到，服务端是决策中心，负责综合user_activity和ping两类信号，做出最终判断；而Redis 扮演了状态中转站的角色，存储会话元数据、最后活跃时间、用户角色等信息，便于横向扩展时共享状态。

此外，安全模块需验证所有续期请求的真实性，防止攻击者伪造user_activity来维持非法会话。常见做法是结合签名机制或短期 Token 更新。