同样是在 2D 无限画布上把两张卡片用箭头连起来，Obsidian Canvas 和 Heptabase 在底层干的是完全相反的两件事。FluxLinks 近期发布的一份架构拆解报告捅破了这层窗户纸。在 Obsidian Canvas 里，这根线只是保存在单个 .canvas 文件里的视觉坐标，你的笔记库图谱（Graph View）对此一无所知；而在 Heptabase 里，这根线会立刻写入两张卡片的底层档案，哪怕你离开白板，卡片也记得自己和谁连过、在哪块白板上连的。
这两款软件代表了空间笔记（Spatial PKM）的两条死胡同。Obsidian 守住了本地文件所有权，代价是画布与核心双链引擎割裂；Heptabase 实现了跨白板的上下文累积，代价是把用户的空间关系锁进专有数据库。看清 2024 年 3 月 11 日发布的 JSON Canvas 1.0 规范 与全局卡片架构的底层冲突，能帮你在塞进上千张卡片前少踩一次迁移大坑。
一根箭头背后的源码级撕裂
Obsidian 的立身之本是本地纯文本 Markdown 文件夹。为了不污染原生的 .md 文件，Obsidian 将画布设计成另一种独立文件。翻开官方的 JSON Canvas 1.0 规范就能看懂它的局限：一个 .canvas 文件的顶层结构只有 nodes（节点）和 edges（连线）两个数组。
规范里把节点分为 4 类：直接写字的 text、引用外部笔记路径的 file、网页链接 link 以及分组框 group。致命的设计在于 edges 数组——当你从笔记 A 拉一根箭头到笔记 B，JSON 里记录的是 fromNode 和 toNode，它们绑定的只是这两张卡片在当前画布里临时生成的局部节点 ID，而不是笔记文件本身的 URI，更不会往 Markdown 正文里写入 [[双链]]。
这就带来了两个直接后果：
- 画布内建卡片沦为反向链接盲区.Obsidian 官方文档明确承认，直接在画布上双击打字生成的纯文本卡片（
type: text），只活在这个.canvas文件内部，根本不会出现在反向链接（Backlinks）面板里，除非你逐一右键点击“Convert to file...”把它们转成独立的.md文件。 - 笔记对空间上下文完全失忆.哪怕你把现有的
.md文件拖进十块不同的画布，画布也只是从外部调用了文件路径。当你回到常规编辑器打开这篇笔记，它不知道自己正躺在哪些画布上，不知道旁边挨着哪张卡片，也看不见指向它的箭头标签。
Obsidian 社区论坛（编号 62279 讨论帖）里，大量用户抱怨画布连线无法在全局图谱中显示，有人甚至专门写了 Canvas Links 插件来打补丁。但插件只能修补嵌入引用，改不了“视觉层与核心链接引擎分离”的底层架构。
Heptabase 则彻底抛弃了“文件容器”概念。它的官方架构文档写得很直白：白板不拥有卡片，所有卡片都属于中央卡片库，白板只是映射卡片的非拥有型视图。
同一张原子卡片可以同时摆在五块白板上，一处修改处处同步。你在任意白板上给卡片 A 和卡片 B 连线，两张卡片各自的 Card Info 面板都会立刻记录下这段关系、连线所在的白板名称，并提供一键跳回该白板精确坐标的入口。上下文跟着卡片走，而不是被困在画布文件里。
戳破“开放格式”与“支持导出”的幻觉
很多测评文章写到这里，会顺手给出一句庸俗的结论：要数据开放选 Obsidian，要体验内聚选 Heptabase。我不太买账的是，这种二元划分掩盖了双方在数据迁移上的真实损耗。
开放的格式不等于无损的迁移，能导出文字也不等于能带走思考。
先看 Obsidian 引以为傲的 JSON Canvas 开放标准。它确实没有厂商锁定，任何第三方脚本都能解析 .canvas 文件。但这是一种典型的“伪可移植性”：如果你在画布里混用了大量未转成独立文件的 text 节点，或者依赖特定插件渲染视图，换个软件打开时，文件相对路径和内建文本的割裂依然会让知识库支离破碎。更何况，原本就没有被索引进核心图谱的视觉连线，迁出去了也只是一堆XY轴坐标数据。
再看 Heptabase 的导出承诺。它允许用户随时把所有卡片导出为标准 Markdown 文件，看着很良心。但当你真正执行导出时就会发现，你精心排布的白板只能导出为静态图片或线性的卡片列表。那些跨越不同白板、在 Card Info 里双向追踪的空间连线和拓扑结构，无法导出为 JSON Canvas 这类开放交互格式。
这就像早年互联网从本地客户端向 SaaS 云端迁移时的旧剧本重演。《战国策》有言，“抱薪救火，薪不尽，火不灭”。工具厂商为了解决纯文本在空间表达上的贫瘠，引入了关系型数据库这捆“薪”，却顺手把用户最值钱的关系资产锁进了自家的云端架构里。Heptabase 给你的只是内容备份，而不是工作区备份。
2D 白板的共同天花板与选型自测
即便不谈底层存储，这两款工具还面临一个共同的认知瓶颈：2D 空间白板天生不适合直接产出严密的长文。
你在白板上从 A 拉一根箭头到 B，这根线只有空间方向，没有逻辑语义——它没法标明 A 到底是在支持 B、反驳 B，还是作为 B 的前提条件存在。更麻烦的是，人类的阅读习惯依然是线性的。当你准备把一张铺满上百张卡片的 2D 画布变成一篇结构严密的报告时，你还得自己动手把二维网状坐标“压平”成一维段落，大量思考时的逻辑骨架就折损在这个翻译过程里（这也正是撰写该报告的 FluxLinks 试图用“显式命题树”去切入的空白市场）。
如果你正在这两者之间摇摆，别看宣传片里的画布有多丝滑，按自己的真实产出目标做决定：
- 建议.拿白板画项目路线图、系统架构草图或单次头脑风暴，选 Obsidian Canvas，并在把卡片拖上画布前先建好
.md文件，绝不用画布自带的纯文本卡。 - 风险.做跨学科、长周期的文献综述与卡片盒积累时，Heptabase 的全局卡片能省下大量维护上下文的精力，但请做好一旦停订或迁移就会丢失全部空间关系图的心理准备。
接下来最值得盯紧的行业变量只有一个：JSON Canvas 规范在后续版本中，敢不敢在 edges 数组里引入语义级的链接属性，让画布上的那根箭头真正写进本地知识库的图谱底层。