Standard Notes 介绍与选型指南

Standard Notes 定位、零知识架构与版本现状全貌，与 Joplin/Notesnook/Obsidian+Sync 的量化选型对比及微服务架构与自托管能力边界

Standard NotesStandard Notes2026/11/02

Standard Notes 介绍与选型指南

目标：把 Standard Notes 的定位、零知识加密架构、版本与项目现状、微服务架构全貌讲清楚，并与 Joplin、Notesnook、Obsidian+同步方案做可核对的选型对比，回答"什么场景该选它、什么场景不该选"。

本文的架构与加密行为结论均来自 2026-11-02 对 standardnotes/server 镜像（tag 3125ba9212fe7c1f8b635017babdb726778ff26e，对应 3.3.2 版本线）自托管栈的实测取证，部署过程见本专栏《Standard Notes Docker Compose 部署指南》一篇，API 协议级实测见《Standard Notes 3.3.2 API 使用详解》一篇。

1. 它是什么

Standard Notes（standardnotes.com）是一款端到端加密（E2EE）的笔记与文档应用，现归属于 Proton 旗下。它的核心主张是零知识（zero-knowledge）：

  • 笔记内容在客户端加密后才发往服务器，服务器只存储密文；
  • 加密密钥由用户密码在本地派生，密码本身和派生出的密钥都不上传；
  • 自托管场景下，数据库、对象存储、消息队列全部在你自己的机器上，连元数据都不出家门。

这不是宣传口径，而是可以实测验证的行为。我们直接对服务器 API 提交一条"密文"并查库核对：

POST /v1/items 提交的 item：
{"uuid": "79d80785-...", "content_type": "Note",
 "content": "{\"encrypted\": \"U2FsdGVkX1+F3NoteV1==\"}"}

落库后（MySQL standard_notes_db 的 items 表）原样存这段密文，
服务器全程不解析、不理解 content 字段的内容；
GET /v2/login-params 之类的接口也只回 identifier / pw_nonce / version
这几个密钥派生参数，不回任何秘密材料。

客户端矩阵齐全：Web（静态 SPA）、桌面（Mac/Windows/Linux，Electron）、iOS、Android，全部开源。

2. 项目现状与版本口径（2026-11-02 实测溯源）

项目数据来源
standardnotes/app（客户端 monorepo）约 6.7k starsshields.io 徽章实测
standardnotes/server（服务端 monorepo）481 starsGitHub 页面实测
最新 release@standardnotes/desktop@3.202.11shields.io 徽章实测
自托管 server 镜像 tagcommit sha 3125ba9212fe7c1f8b635017babdb726778ff26edocker 镜像实测
应用版本线3.3.2实测 API 交互
协议版本号004（会话体系）/ 003 / 002 / 001实测注册与落库

这里有一个新手极易踩的版本双轨坑：3.3.2 是应用版本，004 是加密协议版本，两者不能混用。注册账号时 POST /v1/users 的 version 字段必须填协议版本号 "004"；如果填了应用版本 "3.3.2"，服务器会静默回退到旧版 JWT 鉴权体系，账号拿不到 session 会话（GET /v1/sessions 报 unsupported-account-version），后续改密、多设备会话管理全部受限。这一点我们在协议实测中完整复现过，详见《Standard Notes 3.3.2 API 使用详解》一篇。

Star 数获取说明：当日 GitHub 直连与代理均超时，改用 shields.io 徽章接口取数（img.shields.io/github/stars/standardnotes/app），数值为 2026-11-02 快照。

3. 核心特性

端到端加密同步。 每个条目（笔记、标签、文件夹、设置）都是独立的加密 item，客户端生成/更新密文后经 POST /v1/items 同步，服务器只做密文存取和冲突协调（conflicts/unsaved 字段），凭 sync_token 支持增量拉取。

条目版本历史（revisions）。 每次更新密文会生成版本，可通过 GET /v2/items/:uuid/revisions 列出并取回历史密文，由客户端解密回看。版本保存频率有付费档位差异（配置项 REVISIONS_FREQUENCY / FREE_REVISIONS_FREQUENCY）。

文件附件。 独立的 files 微服务，支持本地磁盘或 S3 兼容对象存储，上传凭 auth 服务签发的 valet token（短期凭证）授权。

多设备会话体系（004 协议）。 登录返回 access/refresh 双令牌与过期时间戳，GET /v1/sessions 可列出全部会话并标记当前会话，登出返回 204 并吊销该会话；改密会吊销其他会话。

共享保管库（Shared Vaults）与紧急访问。 协议字段 shared_vault_uuid、emergency_access_invitations 表、PREDICATE_VERIFICATION_* 配置项，支持把加密库授权给他人或设置紧急联系人。

扩展机制。 编辑器、主题、备份等以扩展形式提供。注意：官方云端的多数高级扩展挂在付费套餐后面；自托管基础版开箱提供的是基础编辑器与加密同步能力，付费订阅体系（payments 微服务）在自托管环境基本用不上。

长期存续承诺。 官方对代码开源、可自托管、数据可导出的强调较多，2024 年起与 Proton 深度绑定（后并入 Proton 体系），背书了持续维护与审计能力。

4. 架构总览

官方自托管把整个后端打包为一个 server 镜像，内部是 Node.js 微服务 monorepo，由 supervisord 统一拉起。我们在容器内实测到 9 个 node 进程（5 个 entrypoint-server.js + 3 个 entrypoint-worker.js + 1 个入口），监听端口如下：

端口服务职责
3000API Gateway唯一对外 API 入口，路由/代理到内部微服务
3101auth注册/登录/会话/改密/令牌签发
3103syncing-server条目存取与同步（密文保管员）
3104files文件附件服务（宿主侧映射到 3125）
3105revisions条目版本历史
50051 / 50052gRPC微服务间内部通信

外部依赖三件套：

  • MySQL 8：唯一持久化存储，37 张表（users / sessions / items / revisions_revisions / shared_vaults / emergency_access_invitations 等）；
  • Redis 6：缓存 + 微服务间消息队列 + 登录限流计数（lock:<userUuid>）；
  • localstack：模拟 AWS SNS/SQS，承载服务间事件总线（7 个 topic、3 个 queue，由 bootstrap 脚本初始化）。

Web 前端与后端分离：官方帮助文档明确"自托管服务器只是后端，不包含 Web 应用"；前端是编译好的静态 HTML/JS/CSS，可用 standardnotes/web 镜像或自行构建 standardnotes/app 的 web 包部署，index.html 里注入 window.defaultSyncServer 等全局变量指向你的服务器。

5. 选型对比

与三类典型"加密笔记/知识管理"方案的横向对比（均基于公开事实与本平台实测）：

维度Standard NotesJoplinNotesnookObsidian + 同步
加密模型端到端加密，服务器只见密文（实测）E2EE 为可选开关，按笔记粒度启用端到端加密本体无云端；官方 Sync 付费且加密，第三方同步取决于目标存储
数据形态专有 item 密文，导出依赖客户端Markdown + SQLite专有格式密文本地纯 Markdown 文件
自托管服务端官方支持，单镜像 + MySQL/Redis/localstack 五件套官方支持，Joplin Server 单镜像 + PostgreSQL，也可纯 WebDAV/S3官方对自托管支持有限无服务端（或 Remotely Save 插件对接 S3/WebDAV）
部署复杂度中：5 容器，需初始化消息队列与前端注入低-中：2-3 容器即可闭环高：组件多、文档少最低：只要一个对象存储
移动端iOS/Android 官方客户端iOS/Android 官方客户端iOS/Android 官方客户端官方移动端，同步靠插件/付费
附件files 服务（本地/S3）跟随同步渠道云端存储本地文件系统
版本历史服务端保存密文版本（revisions）无服务端历史有依赖 Git/插件
插件生态扩展体系，高级扩展偏付费插件市场活跃内置功能为主社区插件极繁荣
项目活跃度（2026-11）app 约 6.7k★ / server 481★，Proton 背书社区驱动，版本线 3.7.x商业公司驱动商业公司驱动，闭源内核

各方案的取舍本质是三角权衡：零知识强度、数据可迁移性、功能丰富度。

  • 要"服务器绝对看不到明文"且官方自托管闭环完整 → Standard Notes 是少数把这句话实测得通的方案；
  • 要"本地 Markdown 文件永远可读、插件生态大" → Joplin 或 Obsidian 更合适，Joplin 的部署成本也明显更低（可参考本平台 Joplin 专栏的部署实测：两三个容器即可跑通同步闭环）；
  • Notesnook 加密模型与 SN 接近，但自托管路径官方支持有限，适合直接用其云端；
  • Obsidian 走"本地优先 + 自带存储同步"路线，零知识与否完全取决于你挂的存储桶。

同属"文档/知识管理自托管"赛道的 Papermerge、SeedDMS 等 EDMS 类组件与 SN 定位不同（面向扫描件/文档归档而非笔记），选型时不要混淆，可参考本平台对应专栏的介绍篇。

6. 什么时候选它 / 不选它

适合：

  1. 隐私是硬需求：医疗、法律、个人日记等"服务商也不能看"的场景；
  2. 想要完全自托管：数据、密钥、同步、附件全部落在自己机房，无外部依赖；
  3. 多设备纯笔记工作流：写-改-同步为主，不重度依赖表格/画板/插件；
  4. 需要账号级安全治理：会话列表审计、改密吊销、紧急访问、共享保管库。

不适合：

  1. 需要本地明文 Markdown 文件（双链笔记、Git 管理）——SN 的数据在库里就是密文，无法直接当文件用；
  2. 重度排版、复杂表格、白板、画图等富媒体需求——基础编辑器能力有限，高级编辑器多在付费墙后；
  3. 团队协同编辑——SN 的共享是保管库授权模型，不是实时协作；
  4. 追求最小部署面——它的"官方自托管"是 5 容器全家桶（含 MySQL/Redis/localstack），比 Joplin Server 重。

7. 专栏导航

本专栏按"选型 → 部署 → 配置 → API"四篇展开：

8. 跨栏相关阅读

9. 参考来源

  • github.com/standardnotes/app（客户端 monorepo，Web/桌面/移动源码与 README）
  • github.com/standardnotes/server（服务端 monorepo，自托管 compose 样例与 env.sample）
  • standardnotes.com/help/self-hosting（官方自托管帮助：架构总览、微服务职责、Docker 支持口径）
  • standardnotes.com/longevity（项目存续承诺）
  • 本平台实测：自托管栈协议级取证（注册/登录/同步/版本/改密/登出全链路原始回显）、容器进程与端口盘点、MySQL 落库核对、shields.io 项目数据快照（2026-11-02）