不知道你最近有没有刷到过这类问题社区里有人发了句“我想做一个跟 libtv 一样的无限画布”下面跟着一堆讨论。说真的每次看到“无限画布”这词我都想先拦住对方聊十分钟——不是拦着不让做而是很多人在动手之前根本没搞清楚自己要的到底是“无限画布”这个噱头还是它背后那种“把信息自由摊开”的体验。做了几年前端和可视化相关工作我自己也在不同项目里被“无限画布”坑过几次也靠它救过几次场。这玩意儿被神化得很厉害好像产品里塞一个无限画布就自动拥有了 Figma 的丝滑、Miro 的协作感、Obsidian Canvas 的灵性。实际情况根本不是这么回事。无限画布不是“能不能做出来”的问题而是“它到底适不适合你这个赛道”的问题。不同赛道的产品对画布的交互要求、渲染要求、数据模型要求完全不同照搬别人家的画布方案基本就是一场灾难。这篇文章我想从一个实操者的角度把无限画布在几个典型赛道里的适配逻辑拆开聊聊顺便整理一下如果真要动手做一个该从哪里排优先级、会踩哪些坑。内容偏产品和前端技术向但我会尽量说人话没接触过画布开发的人也能看懂个七八成。一、先想清楚你想要的到底是“无限”还是“空间化组织信息”1.1 一个典型需求背后的真实动机先说开头那个“我想做一个跟 libtv 一样的无限画布”。这类需求我见过太多次了今天社区里冒出个类似产品明天就有人想复刻一个。问题在于大家看到的是成品没看到成品背后那一堆基于赛道特性的取舍。无限画布这四个字听起来像是一个“功能”但实际它更像一个“容器”。容器本身不产生价值容器里装的东西、操作容器的方式才决定产品是真好用还是花架子。同样一个画布在 Figma 里是像素级设计工具的操作台在 Miro 里是头脑风暴的公共墙在 Obsidian Canvas 里是知识文档的可视化索引。它们都叫无限画布但你要是把 Figma 的交互逻辑塞进笔记产品里用户会直接疯掉。所以每次有人跟我说“我想做一个无限画布”我第一反应不是“用什么技术方案”而是反问一句你的用户在这个画布上要完成什么任务他是在画图、在写文档、在跟人讨论还是在整理一堆卡片任务不同画布的底层设计完全不是一回事。1.2 无限画布的本质一张永远铺不满的桌子我平时跟人解释无限画布特别喜欢用一个类比它就像一张永远铺不满的大桌子。你从文件夹里把资料抽出来一张张摊在桌面上想怎么摆就怎么摆。跟传统的树状文件夹、列表式文档比画布给了你一种“空间位置即信息关系”的能力——东西摆得近说明它们相关摆得远说明它们暂时没关系。这个能力天然适合那些需要“同时参照多个信息块”的任务。比如梳理一个项目的全局逻辑、头脑风暴发散想法、整理一本复杂书的章节关系这些场景下列表和树是真的不够用因为信息之间的关系是多对多的、非线性的硬塞进树状结构里就是在削足适履。但问题也出在这儿大桌子只是解决了“摊开”的需求它不帮你“收拾”。信息一旦多了几千张卡片全堆在桌面上找东西靠缩放、靠平移、靠记忆这时候画布反而成了负担。很多做无限画布的产品最后都死在这个地方——他们保证了用户可以无限地放东西却没保证用户能无限地找回来。这不是技术问题是产品认知问题。二、不同赛道对画布的真实需求差得有多远2.1 设计工具赛道精度和操控才是命根子先看 Figma 这类设计工具。它的画布确实是“无限”的但你去问一个设计师Figma 最吸引他的点是什么他大概率会说是“精确到像素的对齐”“0.1px 的微调”“缩放任何比例线条都保持清晰”而不是“画布无限大”。设计工具里的无限画布本质是一个背景板。核心工作是矢量编辑、图层管理、约束布局、阴影和样式的实时预览。这意味着画布本身的实现要求非常高缩放要无级连续不能跳变滚动要跟手元素在极低缩放下要做降级渲染在高缩放下要保持锐利。你还需要一个极强大的吸附系统让用户拖个框就能自动跟旁边元素对齐。这个赛道的画布知识密度极高抗抖动、抗误差的要求也极高。你要是用一个纯 DOM 方案去做元素一多直接卡成 PPT你用 Canvas 做又得自己处理复杂拾取、命中测试、图层重绘顺序。我见过不少团队雄心勃勃想做一个 Figma 替代品最后死在了“看似简单但细节多到爆炸”的交互精度上。2.2 团队协作白板赛道实时性和对象模型优先Miro、tldraw、Excalidraw 这一类协作白板是无限画布最“正统”的赛道。这里用户的核心任务不是精密制图而是在一块大板子上快速表达、快速讨论。便利贴、手绘箭头、简单图形、评论标记够了。这类产品里画布是一等公民但重心不在渲染精度而在两件事一是多人实时协作二是对象模型的简单灵活。你画一个矩形本质是往画布数据模型里插入一个“shape 对象”其他人客户端要立刻看到它出现移动它、删除它也要实时同步。这里牵扯到 CRDT、房间同步、光标实时位置广播、离线编辑冲突处理一层一层全是坑。有意思的是这类白板虽然在视觉上很“自由”但数据模型反而极其克制。因为要支持协作和频繁增删对象类型不能太复杂最好就是矩形、椭圆、线段、文本、图片这么几种基础图元。想象一下如果 Miro 的每个对象都像 Figma 那样带着几十个属性协作同步的负担会大到无法接受。所以白板赛道的“无限画布”本质是牺牲精细度换自由度和实时性。2.3 笔记与知识管理赛道画布只是二级交互提到 Obsidian Canvas、Heptabase、Notion 的画布视图我要特别提醒一声这类产品里的无限画布跟上面两类完全不是一个物种。它们不是为了让你在画布上“创作”而是为了让你把已有的文档、卡片、链接关系用空间的方式“看一遍”。拿 Obsidian Canvas 来说它的核心依然是 Markdown 笔记、双链、图谱Canvas 更像是把这些笔记卡片摆到一张白纸上帮用户快速建立“知识地图”。用户的主要精力还在写作和阅读上画布只是辅助整理思路的手段。这个定位决定了画布不需要像素级对齐不需要多人实时协作但需要跟笔记数据模型深度打通——你在画布上拖一张卡片它得对应到真实存在的文档而不是画布里的一个孤立图形。很多做笔记产品的人一看到无限画布就兴奋觉得加上它产品就成了。但实际做下来会发现画布在笔记里最好的角色是“锦上添花”不是“主角”。因为笔记的核心是长期积累、快速检索、稳定存储而画布天然适合“临时性”的思维整理不适合长期的、体系化的信息沉淀。你让用户把所有笔记都放进一张大画布三个月后他打开画布面对两千张卡片只会想哭。2.4 数据可视化和地图类场景画布由数据规模驱动还有一个比较容易被忽视的赛道就是那种“数据多到必须用空间承载”的场景比如图数据库可视化、城市级信息模型、物联网设备分布图。这里画布的“无限”不是产品设计的选择而是数据规模撑出来的必然——点有几十万个不搞个无限可平移缩放的画布根本放不下。这类场景的技术重心又变了要解决海量图元的渲染性能要做视口剔除只画屏幕内的元素要做 LOD 层级细节缩放级别不同显示的细节不同要做聚合点多了合成簇甚至要上 WebGL 和 GPU 加速。交互反而不是重头因为用户大部分时间在看、在筛选、在定位而不是在画布上画东西。我见过一个做智慧园区可视化的项目里面几千个设备点位在 Canvas 上渲染每帧都要全量重绘帧率掉到十几。后来改成“视口剔除 静态层缓存 交互层重绘”性能才拉回来。这种场景下你如果硬套协作白板那种“每个对象都可实时编辑”的模型机器直接冒烟。三、动手之前必须想清楚的三个技术分叉口聊完赛道差异落到具体做的时候还有几个技术选型必须提前定不然后期返工成本极高。3.1 渲染方案DOM、Canvas 2D、WebGL各守各的边界无限画布的底层渲染方案基本决定了整个项目后续的天花板。我直接给你一个我常用的参考认知。DOM 方案适合节点数在几百以内的“界面型画布”比如流程图工具、小型白板。优势是 DOM 天然自带事件系统、文本排版、可访问性开发效率极高维护也简单。但你让 DOM 管几千个节点绝对卡到你怀疑人生因为每次重绘都要走浏览器排版和重绘流程。Canvas 2D适合几千到几万节点的中等规模画布。缺点是你得自己实现拾取点击命中检测、重绘优化、文本换行、图元命中测试Canvas 本身不给你提供任何高级能力相当于“给你一张纸画什么、怎么画全看你自己”。绝大多数想做无限画布的团队最终都落在这个方案上。WebGL / GPU 渲染适合十万级节点以上、或者需要大量复杂视觉效果模糊、渐变、粒子、海量贴图的场景。开发和调试成本成倍上升数据传到 GPU 也要考虑带宽和纹理限制。做数据可视化、地图类产品再考虑这个方案。我建议新手团队上来不要碰 WebGL。先搞清楚你的对象数量级如果日常使用只是几千个图元Canvas 2D 足够用而且开发效率高得多。等你真碰到性能瓶颈再做局部渲染层的 GPU 升级都比一开始就上 WebGL 划算因为 WebGL 的调试体验实在不太友好。3.2 坐标系统与缩放层级被忽略的“无限”陷阱无限画布听起来是“无限”落实到浮点数上就是个灾难。你先想一个问题当你把画布缩放到 1000% 或者缩到 1%坐标数值会变得非常大或者非常小double 精度够用吗这种情况下对象的位置可能出现肉眼可见的漂移两个靠近的点会黏在一起甚至出现 jitter抖动。现实中没有任何产品会做真正无极限的缩放。你总得定义 minScale 和 maxScale比如 10% 到 1600%超出范围就不再缩放了这是保护浮点精度最直接的办法。但光定义范围还不够更稳妥的做法是在“世界坐标”之上做“分层坐标”原始数据存一份“逻辑坐标”渲染时用矩阵变换把逻辑坐标映射到屏幕尽量避免在交互过程中反复累加偏移量。还有一个常见的实现细节缩放的时候要以当前鼠标位置为锚点而不是以画布中心为锚点。想象你在看一张地图你希望“鼠标指哪儿哪儿就保持在屏幕中心附近不动”这样缩放才有“放大这个区域”的直觉。要是锚点固定在画布中心用户每次缩放都要重新找刚才看的位置体验直接骨折。3.3 数据模型画布对象不是一堆散装图形再一个我特别想强调的点很多人做画布开发一开始就把对象存成“一堆图形”矩形就是 x、y、width、height、fill文本就是 x、y、text、fontSize各存各的。等做到后面要支持撤销、恢复、协作、导入导出时就会发现自己被这堆散装数据坑惨了——根本没法统一处理。更合理的做法是给所有画布元素建一个统一的抽象基类比如CanvasNode下面再派生出ShapeNode、TextNode、ImageNode、GroupNode。每个节点至少有 id、type、坐标、尺寸、图层顺序、可见性这几个通用字段再由各自类型去扩展专属字段。这样一来后面做框选、序列化、批量操作、历史记录都会轻松很多。顺带说一句存储策略也很关键。小规模单机项目直接存一个 JSON 文件完全行得通但一旦涉及协作者你就得考虑是存“对象全量快照”还是“操作记录流”。我个人的判断标准是并发用户少、对象量小就全量快照加版本号并发高、对象多就用 CRDT 或 OT 做增量同步。别一上来就上重方案先看清楚自己的并发红线和数据量级再决定。四、如果真要做一个无限画布我建议这样排优先级还是回到那个“我想做无限画布”的需求。假设你已经想清楚自己的赛道也确认画布确实是核心功能我建议按下面的顺序动手而不是上来就写代码。4.1 先把交互边界写清楚再碰渲染层我见过太多团队做了三个月产品演示时才发现自己连“框选后拖动元素”都没做因为一开始光顾着做“无限”的平移动画了。这就是交互边界没定义死的下场。建议你做一张表把画布的功能能力、优先级、工作量估个大概能力模块说明优先级平移/缩放以鼠标/触控板为锚点缩放平滑跟手P0对象增删改添加基础图形、文本支持拖动、删除P0多选与框选按住拖出选择框批量移动、删除P0撤销/重做对对象操作支持历史回退P1参考线/吸附拖拽时与其他元素对齐辅助P1多人协作光标同步、对象实时同步P2海量对象性能万级对象渲染优化P2你会发现“无限”这个词压根没出现在 P0 列表里。这就是我的核心观点画布的本质是“可缩放平移的空间”而不是“能装多少东西”。先把 P0 做到位哪怕你只支持一个 10000×10000 的逻辑区域用户手感对了比什么都强。4.2 最小可行画布的“最小”到底怎么划我推荐的 MVP 切法是单用户 三种对象类型矩形、文本、图片 平移缩放 框选拖动 撤销重做 导出导入。别再加了真的别加了。这套东西做完你能覆盖大部分二维表达需求而且每一块工作量都可控。以 Canvas 2D 为例我粗略估下工时坐标变换和交互约占 3 天画布对象模型占 3 天渲染循环和视口裁剪占 2 天框选和命中检测占 2 天撤销重做如果做轻量快照占 1 天导出图片占 1 天。一个人全职做大概两周能出个能用的小原型。要是你把多人协作也塞进 MVP工时直接翻倍还不止因为你要引入 WebSocket、CRDT 库、冲突处理、光标广播这些跟“画布本布”的关系不大但会吃掉你大量时间。4.3 性能预算要在一开始就定死性能问题不是后期优化出来的是前期设计出来的。我建议项目第一天就定几个硬指标正常缩放拖动时渲染帧率不低于 50 fps程序首屏加载时间不超过 3 秒支持同时操作 3000 个对象不卡顿。没有这些阈值后期优化就会变成无底洞。首屏加载和连续交互是两个不同的优化阵地。首屏要的是“别把整个画布的数据全塞给前端”要做视口裁剪只加载屏幕范围内的对象配合虚拟化滚动或者瓦片化存储连续交互要的是“重绘不要全量”最好做脏矩形局部重绘或者在缩放过程中降级渲染细节比如缩放动画期间先不画文本松手后再补齐。我这里有个很实用的经验用户感知的流畅度很大程度上取决于“缩放手势的跟手性”而不是渲染帧率本身。哪怕你用 30 帧渲染只要缩放的中心跟鼠标锚点完全一致、偏移几乎为零用户依然会觉得“很跟手”。所以与其纠结 60 帧还是 120 帧不如先把坐标映射的数学公式打磨到极致。五、踩坑实录我在实践中遇到的几个典型问题与排查思路这部分我挑几个真实踩过的坑都是文档里不会写、只有做到那一步才会被恶心到的细节。5.1 屏幕坐标转世界坐标最容易犯的符号错误先说一个非常低级但人人都可能犯的错屏幕坐标转世界坐标时公式永远是worldX (screenX - offsetX) / scale或者等价形式不是乘以 scale。很多人写代码时一拍脑袋觉得放大了就是乘结果鼠标一移对象往反方向飞跑。另外当你写“以鼠标为中心缩放”时需要先记录缩放前的鼠标世界坐标然后应用新 scale再把画布的偏移量调整成让那个世界坐标仍然落在鼠标屏幕位置。公式是缩放前记录worldPos (mouseX - offsetX) / oldScale改 scalenewScale oldScale * factor缩放后重新计算offsetX mouseX - worldPos * newScale这个公式看着简单但我真见过有人把这行逻辑塞进 RAF 循环里每一帧都去重新采样鼠标位置结果缩放过程中对象疯狂抖动。正确的做法是在手势开始的时候锁住参考坐标手势过程中只改 scale等手势结束后再微调偏移量。5.2 “无限”数据怎么持久化不能把整个空间全量存新手最容易犯的错是给画布搞一个“超大二维数组”或者把所有对象 DB 存成一张大表每次保存就把整个画布序列化一遍。哪怕你只有几千个对象一次全量 JSON 序列化加网络传输也是个肉眼可见的耗时操作。更合理的方案是“分区存储”。你可以把整个画布想象成由无数个固定大小的格子组成每个对象在保存时根据它的坐标计算属于哪个格子然后按格子存入数据库。查询时根据当前视口范围算出该加载哪些格子只拉取可视区域附近的“瓦片”数据。这样首屏加载快保存增量小还能顺带为将来的多人协作留好扩展位。导出的时候也会碰到“无限”的尴尬。整张画布导出 PNG你会发现不可能导成一个单文件——画布太长了。要么做成“导出当前视口”要么做成“设置导出范围”要么做“自动分页导出多张图”。这些需求最好在产品阶段就规划好不然开发会疯。5.3 撤销重做栈别把视图操作和对象操作混在一起这是我踩过最深的一个坑。早期我做画布时把“平移”“缩放”也当成一种操作记录塞进 undo 栈里想着方便用户回退视图位置。结果用户只要拖动一个对象后点撤销系统不光把对象移回去还把刚才自己的缩放给还原了画面直接跳到一个完全找不到的位置。这种体验简直精神污染。正确做法是操作历史只记录对“对象数据”的修改比如新增、删除、移动、改样式、分组不记录视图状态。想让用户回到之前看的位置应该单独做一个“视图书签”或“位置历史”功能跟内容撤销完全分开。还有一个小细节连续缩放和平移过程不要给每个帧都记一个全量快照应该只记录一次手势的开始状态和结束状态否则撤销栈会被刷爆。5.4 协作同步的最小可行策略先别急着上 CRDT最后聊一句很多人一上来就列到计划里的“多人实时协作”和 CRDT。CRDT 确实是个好方案但它复杂度很高库选型、冲突语义、对象类型定义都有一堆讲究。如果你只是想让两个人能同时看一个画布最低成本的方案可以是用 WebSocket 广播“对象变化的增量消息”服务端不做冲突解决后写覆盖先写配合离线版本号做轻量校验。这套东西一个人一周能做出来已经能满足大部分内部工具、教学演示场景了。等用户量真大到需要“两个人同时编辑同一个对象也能正确合并语义”的程度再上 Yjs 这类 CRDT 库也不迟。工程上没有银弹只有阶段合适的方案。这个判断标准很重要能省你大量时间。六、画布之外的判断标准你的产品真的需要无限画布吗说了这么多实现细节我想最后回到一个更根本的问题你怎么判断自己到底需不需要画布我总结了三条自测标准基本能过滤掉八成“跟风做画布”的需求。第一用户的核心任务是不是需要“同时参照多个信息块”比如同时看三篇文档、五张设计稿那画布有价值如果用户一次只看一个页面画布就是纯负担。第二用户的信息关系是空间优先还是线性优先如果信息天然是流程式的、一一对应的你该用看板、时间线、列表而不是一张大白纸。第三用户会不会长期维护、反复打开同一张画布如果打开一次用完就扔画布的价值大打折扣因为一张没有人持续维护的画布最后只会变成垃圾场。如果这三条答案都不乐观真心建议就放弃无限画布。纯文本阅读、表格输入、表单填写这些场景列表和卡片比画布强十倍。很多产品经理对画布有执念觉得它是“高级感”的代名词但高级感不能当饭吃用户要的是任务顺利完成不是像电影黑客那样在大屏上拖拽。我自己这几年做下来最大的体会就是无限画布是个了不起的交互范式但它不是万能解药它是一种有很强“偏好性”的工具。那些天天泡在画布里的用户本质上是喜欢“自己掌控信息排布”的那类人而你一旦把大量信息直接丢给他让他自己排布他可能反而会焦虑。真正成功的画布产品都做了一件事让用户在获得空间自由的同时不用承担空间管理的成本。Miro 有框架和模板Figma 有自动布局Obsidian Canvas 有卡片和连接线辅助整理——没有哪个产品敢让用户从零开始面对一张空白无限画布因为那是一种等待填满的焦虑。所以下次再有人跟我说“我想做一个跟 libtv 一样的无限画布”我会先把他拉到白板上画两个框左边写产品目标右边写用户任务。这两个框理清楚了再回来聊技术方案。工程上的难关都好说真正难的是想清楚画布在你的产品里到底是主角、配角还是根本不该登场。别让“无限”两个字遮住你对产品本质的判断。