Trilium Notes

TriliumNext 是 2024 年初由社区从原版 Trilium Notes 接手、并由 TriliumNext 组织持续维护的开源层级笔记与个人知识库应用。原版作者 zadam 将仓库主动移交社区，原因是上游进入维护阶段，而社区希望继续扩展它。这次交接不是“分叉出走”，而是原作者把火种递给了愿意继续跑的人：数据库结构不变，原版实例可以直接换用 TriliumNext，必要时还能降级回去，不丢数据。它采用 AGPL-3.0 许可，TypeScript monorepo 构建，桌面走 Electron、服务端走 Node.js/Express、存储用单文件 SQLite，Docker 单容器即可自托管。截至 2026 年 10 月，项目约 38.5K Star，最近 90 天仍有 247 个新 issue 和 1,158 个 PR 合并，500 位贡献者，版本迭代至 v0.106.1（2026-10-23）——原版已经放缓，接棒者反而跑得更快。

一、TriliumNext 是什么

Trilium 的血脉可以追溯到 2017 年 5 月。zadam 用近七年时间把它打磨成一个“能装下十万条笔记的层级知识库”，但一个人的维护精力终究有限。2024 年初，TriliumNext 作为 fork 出现，目标不是另起炉灶，而是把维护责任从一个人转移到一群人。社区接手后的第一轮工作集中在技术债上：服务端从 Common.js 重写为 TypeScript，Electron 从已 EOL 的 25 升到 31，CKEditor 升级，国际化起步，Windows 安装器替换 zip 包。这些不是用户一眼能看见的功能，但它们是“一个项目能不能再活五年”的地基。

架构上，TriliumNext 是一个 TypeScript monorepo，遵循客户端-服务端架构，即使桌面版也是 Electron 在同一进程里同时跑后端 Express 和前端客户端。存储层用 SQLite（better-sqlite3） 单文件数据库，没有外部数据库依赖；桌面版、服务端和浏览器内 standalone 构建共享同一套核心逻辑——standalone 把 SQLite 编译成 WASM，跑在 Web Worker 里，数据持久化在 OPFS 中，因此离线优先不是一种模式，而是默认形态。这种“一个 SQLite 文件就是整个知识库”的设计，和 Notion 的云端多租户、Obsidian 的本地 Markdown 文件夹都不同：它把结构化查询能力和单文件可备份性放在同一张桌子上。

二、TriliumNext 能做什么

任意深度的层级树 + 笔记克隆——树状结构不是限制，而是知识建模的第一工具。笔记可以放在任意深的树中，同一条笔记可以通过“克隆”出现在多个位置，而不产生重复副本。对于“一份资料既属于项目 A 又属于主题 B”的真实知识组织需求，克隆比标签更接近人的直觉：你是在把一条笔记放到多个上下文里，而不是给它贴一堆扁平标签。

富文本、Markdown、代码、画布与思维导图——不是“支持格式”，而是“同一棵树里放不同形态的知识”。WYSIWYG 编辑器处理表格、图片和数学公式，代码笔记有语法高亮，Canvas 笔记用于自由绘制，思维导图和关系图把笔记之间的链接可视化。TriliumNext 不强制你用 Markdown 写一切，也不要求你把图表导出成图片再贴回来——知识的不同形态在同一个库里共存。

全文搜索、笔记提升与快速导航——十万条笔记规模下的“找得到”。官方宣称在 10 万条笔记规模下性能没有明显衰减，打开速度在毫秒级，全文搜索输入即出结果。笔记提升（hoisting）让你把一棵子树临时当作“当前工作区”，配合快速导航，在深层树中不会迷路。对于长期积累的知识库，“找得到”比“写得漂亮”更重要。

版本历史 + 端到端加密 + 自托管同步——数据主权在三个层面同时成立。每条笔记有版本历史，可以回滚；敏感笔记可以启用端到端加密；同步通过自托管服务器完成，数据不经过第三方云。这三件事放在一起，构成了一个完整的“我的笔记只属于我”的技术承诺，而不是一句营销口号。

脚本与自动化——属性、标签、脚本引擎把笔记系统变成可编程的知识库。Trilium 一直有脚本能力，TriliumNext 延续了这一点：笔记可以带属性/标签，Script Engine 可以响应事件、生成内容、操作树结构。对于愿意写一点代码的用户，这意味着知识库不只是“存储”，还可以是“自动化的工作流”。

Docker 单容器自托管与多架构支持——部署门槛低到一台 NAS 就能跑。官方 Docker 镜像覆盖 AMD64、ARMv7 和 ARM64/v8，单容器挂载一个数据目录即可运行，数据目录里就是那个 SQLite 文件和附件。备份就是复制一个目录，迁移就是搬走一个目录——这种“运维友好”在自托管知识库中不是小事。

三、TriliumNext 适合谁用

需要组织大规模、深度互联笔记的研究者和长期知识工作者。你的笔记不是几十条，而是几千、几万条，且它们之间存在层级、链接、引用和克隆关系。TriliumNext 的任意深度树、克隆、关系图和全文搜索，是为“大规模个人知识库”设计的，而不是为“轻量速记”设计的。官方对 10 万条笔记的定位，指向的正是这类用户。

对数据主权有要求、愿意为自托管付出一次部署成本的自托管用户。你的笔记里有未发表的研究、私人日记、敏感资料，你不希望它们躺在别人的云里。TriliumNext 的单文件 SQLite + 自托管同步 + 端到端加密，让“数据全在我手上”成为可验证的事实，而不是条款里的承诺。

喜欢“结构化 + 可编程”而不是“纯 Markdown 文件夹”的用户。Obsidian 的本地 Markdown 很优雅，但它的组织能力更多依赖文件夹和链接；TriliumNext 给你的是数据库级的树结构、属性、克隆和脚本。如果你想要的是“一个可以查询、可以自动化、可以按任意结构组织的知识库”，而不是“一堆可以链接的文件”，TriliumNext 更接近你要的东西。

从原版 Trilium 迁移而来、希望项目继续演进的老用户。数据库结构不变，迁移没有特殊步骤，必要时还能降级回去。对于已经积累了大量笔记的老用户，TriliumNext 是最低摩擦的继续使用路径：你不用重建知识库，只需要换一个镜像。

在 NAS、树莓派或低功耗设备上自托管知识库的用户。Docker 多架构镜像、SQLite 单文件存储、无外部数据库依赖，让 TriliumNext 在一台 ARM NAS 上就能跑起来。对于“不想为了一个笔记应用维护一套数据库集群”的人来说，这是决定性的。

不适合谁，同样需要说清楚。 如果你想要的是开箱即用、界面现代、移动端体验原生流畅的产品，TriliumNext 不是：它没有原生移动应用，移动端通过浏览器访问服务器，UI 偏功能性而非美观，学习曲线陡峭，被社区明确归类为“power-user tool, not a beginner-friendly one”。如果你需要实时多人协作，TriliumNext 没有这个能力；它是为个人知识库设计的，不是为团队 wiki 设计的。如果你极度依赖移动端写作，社区 issue 中关于移动设备上笔记数量增加后性能严重退化、甚至“几乎无法用于写作”的报告需要认真对待。如果你打算基于 TriliumNext 修改后作为闭源网络服务提供，AGPL-3.0 第 13 条要求你向用户提供修改后的源码，私有化商业分发在这条协议下走不通。

四、TriliumNext 的应用场景是什么

个人长期知识库的“单一真相源”——你有一个积累了多年的研究库，包含论文笔记、代码片段、项目文档、日记和剪藏，它们之间通过树结构、链接和克隆相互关联。TriliumNext 把这些全部装进一个自托管实例，全文搜索秒级响应，版本历史让你敢于修改，端到端加密保护敏感部分。它不是“又一个笔记软件”，而是你知识资产的本地保险库。

从原版 Trilium 无缝接续的自托管迁移——你已经用原版 Trilium 多年，不想因为上游放缓而换工具、导数据、重建结构。TriliumNext 复用同一个数据库，换镜像即完成迁移，降级路径也保留。对于“工具不能打断积累”的人来说，这条迁移路径本身就是价值。

NAS / 家庭服务器上的私有知识中枢——你有一台常开的 NAS，希望它承担文件、媒体之外的知识管理角色。TriliumNext 的单容器、单数据目录、多架构镜像，让它成为 NAS 上最容易部署和备份的知识应用之一；配合反向代理和 HTTPS，手机、平板、桌面都能通过浏览器访问。

脚本驱动的自动化知识流水线——你用属性、标签和 Script Engine 让知识库自动生成索引页、自动更新状态、自动从模板创建笔记。对于愿意写一点 TypeScript/JavaScript 的用户，TriliumNext 的脚本能力把“笔记”变成“可编程的对象”，而不是只能手动编辑的文本。

大规模笔记下的层级组织与可视化——你有数千条笔记，需要按项目、主题、时间等多条轴组织，同时不希望同一份内容在多处重复。克隆 + 任意深度树 + 关系图，让你用结构而不是标签堆叠来表达知识之间的关系。

五、TriliumNext 为什么值得关注

“社区接管”在开源世界里通常意味着分叉、争论和碎片化；TriliumNext 是一个罕见的和平交接样本。原版作者 zadam 主动把仓库转给社区，TriliumNext 组织接手后没有改数据库结构、没有制造迁移摩擦、没有把老用户当新用户对待。社区接手后的第一件事不是加功能，而是还技术债：TypeScript 重写、Electron 升级、国际化起步。这种“先修地基、再盖楼”的顺序，在 fork 项目中并不常见——很多 fork 的第一反应是“证明我比原版强”，而 TriliumNext 的第一反应是“让这个项目能继续健康地跑下去”。

它守住了“单文件 SQLite + 自托管同步 + 端到端加密”这条数据主权的底线，而不是在“云化”浪潮里漂走。在一个笔记应用纷纷走向云端协作、订阅制和托管服务的时代，TriliumNext 的架构选择是反方向的：数据库是你机器上的一个文件，同步服务器是你自己跑的，加密密钥在你手里。这种“不把用户数据当产品”的立场，在 2026 年的笔记工具生态里已经是一种稀缺品质。

“十万条笔记”不是营销数字，而是架构承诺。任意深度树 + 克隆 + SQLite + 毫秒级全文搜索的组合，使它能在个人知识库的规模上保持可用。当然，“能装下十万条”和“在每一种操作下都快”是两件事：社区 issue 中关于展开 3000+ 子节点严重卡顿、移动端随笔记数增长性能退化的报告，说明大规模使用仍然需要用户理解它的性能边界。但至少，它的架构没有在几千条笔记时就逼你换工具。

AGPL-3.0 + 无付费墙，是一条清晰的开放边界。TriliumNext 没有“免费版/专业版”的付费分层，没有功能门控，没有账号体系。它用 AGPL 把“个人使用完全自由”和“闭源商业分发需要回馈”分开：你自己用、团队内部用，几乎无感；你要拿它做闭源 SaaS 卖，协议会要求你开源修改。对于一个知识库工具，这种“不把你的笔记当筹码”的许可设计，和它的自托管定位是自洽的。

现实挑战：它是一把为 power user 打造的重型工具，不是为所有人准备的轻量应用。TriliumNext 的学习曲线陡峭，界面偏功能性，移动端没有原生应用，实时协作缺失；大子树展开和移动端性能是长期存在的 issue 领域。它的 AGPL 许可会限制某些商业 reuse 场景，它的“单文件 SQLite”在带来备份便利的同时，也意味着同步和大文件场景有边界（官方明确说它更侧重知识库而非文件存储，单个 1 GB 文件同步可能失败）。TriliumNext 适合的是愿意为结构化和数据主权付出学习成本的人，而不是想要一个“打开就能写、写完就能同步、界面还很好看”的消费者产品的人。

一句话收束：TriliumNext 是一个由社区从原版手中接过的、把“大规模层级知识库 + 单文件 SQLite + 自托管同步 + 端到端加密”做到成熟可用的开源笔记应用；它的和平交接和技术还债值得尊敬，它的数据主权立场和 10 万条笔记的架构承诺在同类中少见，但它的学习曲线、移动端短板和 AGPL 约束也同样清晰地划定了它的适用边界。如果你要的是一个你能真正拥有、能在自己的服务器上长期跑下去、能装下你十年笔记的结构化知识库，TriliumNext 是目前最值得认真评估的开源选择之一；如果你要的是一个轻量、漂亮、开箱即同步的消费级笔记应用，它可能比你愿意承担的更“重”。