Excalidraw vs Miro：谁才是真正的开源绘图王者？-平芜编程栈

Excalidraw vs Miro：谁才是真正的开源绘图王者？

在远程办公成为常态、敏捷协作日益深入的今天，一张“白板”早已不只是会议桌旁的书写工具。它成了产品构思的起点、架构设计的画布、团队对齐的战场。Miro 凭借丰富的模板和成熟的生态，长期占据着在线协作白板的制高点。但当开发者们开始追问：“我的数据去了哪里？”“能不能不依赖云服务也能协作？”“有没有更轻、更快、更自由的方式？”，一个名字悄然浮现——Excalidraw。

这不是另一个功能堆砌的 SaaS 工具，而是一次对“可视化协作”本质的重新思考。它的崛起，并非靠营销攻势，而是源于技术社区中口耳相传的那句：“这玩意儿，真能用。”

从一张手绘草图说起

打开 Excalidraw，第一眼你会觉得它“太简陋了”：没有炫酷动效，没有花哨控件，所有图形都带着轻微抖动的边缘，像极了你在纸上随手画下的草图。可正是这种“不完美”，打破了人们对“专业图表必须精美”的执念。它降低的不是视觉精度，而是心理门槛——你不再纠结于对齐与配色，而是专注于表达本身。

这种风格背后，是精心设计的渲染算法。Excalidraw 并非简单地贴个滤镜，而是通过rough.js这样的库，在绘制每条线、每个形状时动态添加微小扰动，模拟真实笔触的不确定性。比如一条直线，实际是由多个略微偏移的点构成；一个矩形，则四角略带弧度，边线微微起伏。这些细节让输出结果更具亲和力，也更适合头脑风暴这类强调创意而非形式的场景。

更重要的是，这一切都在浏览器中完成。无需安装客户端，不依赖特定操作系统，甚至连服务器都不必介入——你可以离线使用，所有内容默认保存在本地 IndexedDB 中。只有当你主动导出为.excalidraw文件或分享链接时，数据才会离开你的设备。这种“本地优先”的理念，直击企业用户对数据隐私的核心关切。

协作，真的需要中心化服务器吗？

说到多人协作，大多数人第一反应就是“上云端”。Miro 的做法很典型：所有操作同步到中心服务器，再由服务器广播给其他参与者。这种方式稳定可靠，但也带来了延迟、成本和隐私问题。

Excalidraw 走了一条少有人走的路：基于 WebRTC 的点对点（P2P）协作。

想象一下，两个同事要一起画架构图。传统方式是他们各自连接到 Miro 的服务器，所有笔画先上传再分发。而在 Excalidraw 中，只要双方能建立直接连接，他们的浏览器就会通过加密的数据通道实时交换变更信息，整个过程几乎绕开了第三方。

这背后的机制并不复杂，却极为巧妙：

用户 A 创建房间，系统生成唯一 URL；
用户 B 打开链接，前端通过信令服务器（signaling server）交换连接元信息（SDP）；
双方利用 STUN/TURN 服务器协助 NAT 穿透，尝试建立 WebRTC 数据通道；
一旦连接成功，后续所有画布变更都以差分消息的形式直接传输。

import Peer from "simple-peer"; const peer = new Peer({ initiator: isCreator, config: { iceServers: [ { urls: "stun:stun.l.google.com:19302" }, { urls: "stun:global.stun.twilio.com:3478" } ] } }); peer.on("signal", (data) => { // 将信令数据发送给对方（经由 Socket.IO） socket.emit("webrtc-signal", data); }); peer.on("data", (buf) => { const update = JSON.parse(buf.toString()); applyRemoteChanges(update); // 应用远程更新 });

这段代码看似简单，却是整个协作体验的技术基石。它意味着即使中间信令服务器宕机，只要 P2P 链路已建立，协作仍可持续。这也解释了为何 Excalidraw 在跨国团队间表现优异——数据不必绕道美国数据中心，中美两地用户可以直接通信，延迟自然更低。

当然，现实网络环境复杂多变。并非所有防火墙都允许 P2P 流量穿透。为此，Excalidraw 提供了降级方案：可通过 WebSocket 中继服务进行状态同步。但这更像是“保底策略”，其设计理念始终是尽可能减少对外部基础设施的依赖。

当 AI 开始“听懂”你的想法

如果说手绘风格和 P2P 协作让 Excalidraw 脱颖而出，那么AI 图表生成能力则让它真正具备颠覆性潜力。

过去，画一张微服务架构图可能需要十几分钟：拖拽容器、标注名称、连接箭头……而现在，你只需输入一句自然语言：

“画一个电商系统的微服务架构，包含 API 网关、用户服务、订单服务和商品服务，网关调用三个后端服务。”

几秒钟后，一幅结构清晰、布局合理的初始草图就出现在画布上。这不是魔法，而是 LLM（大语言模型）与图形引擎的深度集成。

其工作流程如下：

前端捕获用户输入的提示词（prompt）；
请求被转发至后端 AI 网关（可自建）；
LLM 解析语义，输出符合预定义 schema 的 JSON 数据，描述元素类型、位置关系、文本内容等；
前端接收响应，将 JSON 映射为ExcalidrawElement对象并渲染。

async function generateDiagramFromPrompt(prompt: string): Promise<ExcalidrawElement[]> { const res = await fetch("/api/ai/generate", { method: "POST", body: JSON.stringify({ prompt }), headers: { "Content-Type": "application/json" } }); const { elements } = await res.json(); return elements.map(el => ({ type: el.type, x: el.x, y: el.y, width: el.width, height: el.height, strokeColor: "#000", backgroundColor: el.bgColor || "transparent", roughness: 3, // 保持手绘质感 text: el.text || "" })); }

关键在于返回的数据必须严格遵循 Excalidraw 的元素规范。例如，roughness参数控制手绘强度，确保 AI 生成的内容与手动绘制风格一致。否则，机器生成的“完美线条”会破坏整体视觉统一性。

这一功能的价值远超“省时间”。它使得非技术人员也能参与系统设计讨论。产品经理可以用自然语言描述想法，即时生成可视草图；新人工程师通过观察 AI 输出的学习常见架构模式。知识传递的门槛被前所未有地拉低。

如何部署一个属于自己的 Excalidraw 实例？

尽管官方提供了 excalidraw.com 的免费服务，但许多企业选择私有化部署，以满足合规与定制需求。得益于其模块化架构，搭建一套内部实例并不困难。

典型的生产级部署包含以下组件：

+------------------+ +---------------------+ | Client A |<----->| Signaling Server | | (Browser + P2P) | | (Socket.IO / Custom)| +------------------+ +----------+----------+ | +------------------+ +----------v----------+ | Client B |<----->| TURN Relay (可选) | | (Mobile/Web) | +---------------------+ +------------------+ ↗ Local Storage / File Export ↓ [AI Gateway] → LLM API (e.g., Ollama, Llama 3)

几个关键考量点：