<!-- title: 本地优先：8个砍后端的开源神器 -->

# 本地优先：8个砍后端的开源神器

## 本期发掘思路

前两轮我们挖了化学仿真和自建地图，这轮换一个正在悄悄重塑应用架构的方向：**本地优先(local-first)**。

它背后的判断很简单——过去十年，应用默认“数据在云端、界面是壳”，结果是转圈的加载动画、离线就瘫痪的表单、以及越写越厚的乐观更新样板代码。而 CRDT(无冲突复制数据类型)、嵌入式 SQLite、浏览器端加密这三块拼图先后成熟，让“数据先落本地、再异步同步、冲突自动合并”从学术论文变成了可用的工程路线。Figma、Linear 这类产品的手感秘密，多少都和这条路线有关。

本期凑齐一整条本地优先栈：**CRDT 引擎、反应式本地存储、服务端同步、一体化 BaaS、账本数据库、端到端加密、无服务器 P2P** 七个环节八个仓库。没有一个蹭 AI 热点，全是踩过真实流量、或正在被真实产品压验的基础设施工具。Star 一律只标量级不写精确数，以仓库页面实时数据为准。

---

## 1｜Yjs：多人协作的数学保险箱

**[github.com/yjs/yjs](https://github.com/yjs/yjs) ｜ Star 量级：万级 ｜ 长期活跃维护**

一句话定位：JavaScript 生态最主流的 CRDT 实现库，协同编辑领域事实上的标准答案。

它解决什么痛点：多人同时编辑一份数据，谁是准的？传统做法靠服务器仲裁，一旦离线、网络分区，冲突就只能靠人肉解决。CRDT 的思路是数学层面的：每端各自改，合并时按确定性算法收敛，**永远不会冲突**——这是本地优先路线的地基。

核心拆解：Yjs 实现了 YATA 冲突解决算法，对外提供 Y.Text、Y.Map、Y.Array、Y.XmlFragment 等容器类型，把“会合并的数据结构”直接递到你手里。它的杀手锏是生态：y-websocket 让你几十行代码自建同步中继，y-indexeddb 负责本地持久化，CodeMirror、Monaco、ProseMirror、Quill 等主流编辑器全部有官方绑定——给现有编辑器加装多人协作，往往一个下午就能跑通。据其仓库文档，JupyterLab 的实时协作功能就构建在 Yjs 之上，这是它抗压能力的最好背书。

上手难度：⭐⭐⭐(需理解数据容器模型)

适用人群：做协同文档、多人表格、白板的团队。商业方向：给企业内网做离线可用的协同模块，私有化协同层是真实付费需求。

---

## 2｜Loro：给移动端重造的 CRDT 新内核

**[github.com/loro-dev/loro](https://github.com/loro-dev/loro) ｜ Star 量级：数千 ｜ 高频发版中**

一句话定位：Rust 写的新一代 CRDT 库，把冲突合并做到了移动端友好的性能量级。

它解决什么痛点：Yjs 统治 JS 生态，但手机笔记、画板类应用真正的战场在移动端——大文档的内存占用、快照体积、合并速度，老一代实现开始吃紧；而且树形结构、富文本这类复杂数据，在老库里建模别扭。

核心拆解：Loro 纯 Rust 实现，通过 WASM 桥接 JS,并面向 Swift、Kotlin 等多端输出绑定，一套内核全平台复用。内置的容器相当齐：富文本、可移动列表、树结构、Map、计数器，白板和笔记应用要的形状基本都有。两个工程亮点值得单独说：一是快照采用紧凑二进制编码，导入导出速度快、体积小，适合当文档的“存储格式”；二是版本管理能力——文档可以回拨到任意历史版本做检查(checkout),天然适合做时间旅行式撤销和版本对比。项目已发布 1.0,处于快速上升期。

上手难度：⭐⭐⭐

适用人群：做笔记、白板、绘画类移动 App 的团队。商业方向：为同类产品提供同步内核的授权与定制，这类底层咨询客单价不低。

---

## 3｜TinyBase：本地数据的反应式管家

**[github.com/tinybase/tinybase](https://github.com/tinybase/tinybase) ｜ Star 量级：数千 ｜ 持续活跃维护**

一句话定位：本地优先应用的反应式数据层，本期第一个“小而美”选手。

它解决什么痛点：数据搬到本地之后，新问题来了——内存里的表格怎么驱动 UI 精准更新？怎么建索引、连关系、跑查询？怎么持久化到 IndexedDB 或 SQLite?这些零件标准库一个都不给。

核心拆解：TinyBase 用 setRow、addRow 这类直接了当的 API 管理表格数据，核心卖点是细粒度响应式：你改一个单元格，只有依赖它的组件重渲染，大表也不卡。在基本表格之上，它补齐了 indexes(建索引)、relationships(表关系)、queries(类 SQL 查询)三个模块，几乎是一套塞进浏览器的迷你数据库。最妙的是 Persister 体系：数据可以一键持久化到 IndexedDB、OPFS 里的 SQLite,甚至通过适配器和 Yjs、Automerge 双向桥接——本地状态和 CRDT 同步两条路线，它一个库全接上了。作者前 Meta 工程师 James Pearce,典型的个人精品项目：文档极佳、示例完善，一个下午能上手。

上手难度：⭐⭐

适用人群：前端工程师、离线 PWA 开发者。商业方向：离线可用的现场作业类应用(巡检、盘点)外包，交付速度极快。

---

## 4｜Electric：把 Postgres 同步进每一台设备

**[github.com/electric-sql/electric](https://github.com/electric-sql/electric) ｜ Star 量级：数千 ｜ 高频迭代**

一句话定位：Postgres 读路径同步引擎——数据库的子集，直接流式同步到客户端。

它解决什么痛点：前端拿数据的主流方式还是“请求-响应”，于是有了 loading 转圈、请求瀑布、手写缓存失效和乐观更新。Electric 的主张是：别请求了，**订阅**——你圈定 Postgres 里的一块数据，它负责让这块数据在客户端永远保持最新。

核心拆解：核心概念叫 Shape,一条 where 条件圈出你要的数据子集(比如“我这个团队的任务”)，Electric 的同步引擎(Elixir 写就)监听 Postgres 变更，通过 HTTP 把子集增量推到端上，客户端离线时也不影响本地读写，恢复在线自动续传。它不绑定前端框架，可以喂给任意本地存储；与 TanStack 生态的官方适配让它能直接嵌进 React 数据流。这个项目的重生故事很值得玩味：老版本做双向多主同步过于理想化，团队砍掉重来只做读路径同步，反而迅速起量——做基础设施产品的人都该看看这个案例。

上手难度：⭐⭐⭐

适用人群：SaaS 前端团队、需要离线能力的中后台。商业方向：私有化部署同步层，替客户省掉一个自研同步小组，是本期商业价值最清晰的仓库。

---

## 5｜Instant：三天做出多人应用的现代 Firebase

**[github.com/instantdb/instant](https://github.com/instantdb/instant) ｜ Star 量级：数千 ｜ 持续活跃运营**

一句话定位：开源的现代版 Firebase,图数据库加实时订阅加权限，一条命令连上。

它解决什么痛点：想快速做个多人应用，却发现后端、实时推送、权限、离线缓存四座大山全要自己扛。Firebase 证明了这个需求存在，但对国内开发者和私有化场景都不友好。

核心拆解：Instant 的底座是三元组存储，查询语言用的是 Datalog 风格——写查询像在描述“我要什么”而不是“怎么关联”，跨关系遍历非常顺手。前端接入极简：装 `@instantdb/react`,一个 useQuery hook 订阅数据，数据一变组件自动更新，自带本地缓存和乐观更新，多人协作的手感开箱即得，权限用声明式规则描述。云端托管版免费额度够个人项目用，商业模式就是 BaaS 按量收费——它是这期里唯一“本身就是一门生意”的仓库，代码开源、架构透明，既能直接用，也适合研究一家现代 BaaS 该怎么设计。

上手难度：⭐⭐

适用人群：独立开发者、黑客松选手、快速验证产品的初创。商业方向：用它极速交付客户项目；或在理解其架构后，面向内网场景做自建实时后端。

---

## 6｜Fireproof：浏览器里的可靠账本

**[github.com/fireproof-storage/fireproof](https://github.com/fireproof-storage/fireproof) ｜ Star 量级：千级 ｜ 持续迭代**

一句话定位：为 Web 应用设计的账本式(ledger)文档数据库，CouchDB 血统的本地优先新作。

它解决什么痛点：端上存储大多是“一改就覆盖”的盲盒——写坏了无法回退，想同步要自己造版本管理。而聊天记录、操作日志这类数据，恰恰需要“每一步都可追溯”。

核心拆解：Fireproof 的核心模型是**不可变账本**：每次写入都是一条带内容寻址的账本条目，旧数据永不覆盖，所以时间旅行、审计追溯是免费送的。在这个底座上提供实时查询(live query)和 React hooks(useFireproof),写起来像用一个轻量 NoSQL。它的同步哲学很特别：数据块在本地加密后，可以放到任意对象存储(S3、IPFS 等)当同步通道——没有服务器参与业务逻辑，存储只当 dumb 管道。据项目介绍，其主导者正是 CouchDB 联合作者 J Chris Anderson,把十几年分布式数据库经验浓缩成了几 KB 的浏览器库。

上手难度：⭐⭐

适用人群：做 AI 对话应用(历史可追溯)、协作工具的前端。商业方向：需要端侧审计留痕的场景(销售外勤、质检拍照)做定制存储层。

---

## 7｜Evolu：同步可以，明文不行

**[github.com/evoluhq/evolu](https://github.com/evoluhq/evolu) ｜ Star 量级：千级 ｜ 持续维护**

一句话定位：端到端加密的本地优先数据栈，本期第二个小而美。

它解决什么痛点：本地优先的同步方案大多默认“服务器可以看数据”，笔记、健康记录、财务数据落在别人服务器上永远是明文。Evolu 的回答：**服务器只配 seeing 密文**。

核心拆解：数据全部存在设备端 SQLite——浏览器环境走 WASM SQLite 配 OPFS 持久化，性能是真正的本地库而非模拟。同步前在本地完成加密，服务器只转发它读不懂的数据块；账号体系也别出心裁：一串公私钥就是账号，没有邮箱没有密码，换个设备导入密钥即完成迁移。Schema 用 TypeScript 直接定义，类型即校验，前后端一种语言；React hooks 集成顺滑，同步服务器支持自托管，关起门来用也不求人。整个项目体量小、目标纯粹，是“解决单一痛点、设计优雅”的教科书样本。

上手难度：⭐⭐⭐

适用人群：做笔记、健康、财务等敏感数据应用的开发者。商业方向：医疗、法务等隐私合规场景的本地优先方案，合规溢价高。

---

## 8｜Trystero：两个浏览器如何私奔

**[github.com/dmotz/trystero](https://github.com/dmotz/trystero) ｜ Star 量级：数千 ｜ 社区活跃**

一句话定位：无服务器的 P2P 房间库，一行代码让两个浏览器找到彼此。

它解决什么痛点：WebRTC 本身免费又直连，但有个尴尬的前置问题——双方怎么交换连接信息(信令)？标准答案是自己搭一台 WebSocket 信令服务器，门槛劝退了无数想做小工具的人。

核心拆解：Trystero 的脑洞是把信令外包给**现成的免费基础设施**：BitTorrent tracker、Nostr 中继、MQTT、IPFS、Supabase、Firebase 等策略任选其一，两个浏览器借道公共设施互留纸条、交换完连接信息，之后数据全部 P2P 直连，服务器退场。API 极简：joinRoom 拿到房间句柄，就能收发消息、广播状态、传文件，全程纯前端。代价也要清楚：公共信令依赖第三方可用性，不适合硬实时大规模场景，做双人小游戏、结对工具、临时传文件这类“小而直连”的需求恰到好处。整个库零部署、零账单，是本期最轻快的一个。

上手难度：⭐⭐

适用人群：做多人小游戏、互动小工具的前端。商业方向：给在线教育、协作白板类小工具做零成本多人化改造。

---

## 横向对比

| 仓库 | 环节 | Star 量级 | 上手难度 | 适用场景 |
|---|---|---|---|---|
| [Yjs](https://github.com/yjs/yjs) | CRDT 引擎 | 万级 | ⭐⭐⭐ | 协同文档、多人编辑 |
| [Loro](https://github.com/loro-dev/loro) | 新一代 CRDT | 数千 | ⭐⭐⭐ | 移动端笔记、白板 |
| [TinyBase](https://github.com/tinybase/tinybase) | 本地反应式存储 | 数千 | ⭐⭐ | 离线 PWA、精细 UI 同步 |
| [Electric](https://github.com/electric-sql/electric) | 服务端读同步 | 数千 | ⭐⭐⭐ | SaaS 前端、Postgres 订阅 |
| [Instant](https://github.com/instantdb/instant) | 一体化 BaaS | 数千 | ⭐⭐ | 快速上线多人应用 |
| [Fireproof](https://github.com/fireproof-storage/fireproof) | 账本数据库 | 千级 | ⭐⭐ | 可追溯端侧数据 |
| [Evolu](https://github.com/evoluhq/evolu) | 端到端加密栈 | 千级 | ⭐⭐⭐ | 隐私敏感应用 |
| [Trystero](https://github.com/dmotz/trystero) | 无服务器 P2P | 数千 | ⭐⭐ | 双人工具、小游戏 |

> 注：本篇成稿环境无实时联网核验通道，Star 数为写作时点的量级判断，请以各仓库页面实时数据为准。

## 一张图看懂这条本地优先栈

```mermaid
flowchart TD
    A["本地优先应用"] --> B["Yjs CRDT 引擎"]
    A --> C["TinyBase 本地状态"]
    B --> D["Loro 移动端内核"]
    C --> E["Fireproof 账本存储"]
    B --> F["自建同步中继"]
    F --> G["Electric 读路径同步"]
    G --> H["Postgres 业务库"]
    A --> I["Instant 一体化 BaaS"]
    A --> J["Evolu 端到端加密"]
    A --> K["Trystero P2P 直连"]
```

上手路径建议分三步：先用 Instant 或 TinyBase 感受“数据在本地”的开发手感；需求升级到多人协作，再引入 Yjs 或 Loro 做冲突合并；等产品要规模化，才动 Electric 把 Postgres 数据流正式接进来。加密和 P2P 两个仓库按需插入，不必一步到位。

## 本期之最

**最值得立即尝试：TinyBase**。零依赖、文档极佳，npm 装完半小时就能把一个离线待办应用写出“改哪更新哪”的丝滑感，是理解本地优先路线成本最低的入口。

**最有商业潜力：Electric**。“数据库到客户端的同步层”是所有重前端产品的隐形刚需，私有化交付一单抵得上半年订阅费；它砍掉双向同步、聚焦读路径的重生策略，本身就是一份商业教科书。

**最被低估：Evolu**。大多数同步方案都在讨论“怎么合”和“怎么快”，它默默解决了“怎么不让服务器看见”——在隐私法规越来越重的环境里，这个千级 Star 的仓库可能押中了本地优先的最终形态。

## 参考来源

1. [Yjs 官网](https://yjs.dev) — Yjs 文档、算法说明与编辑器绑定生态列表
2. [Loro 官网](https://loro.dev) — Loro 容器类型、快照格式与版本管理文档
3. [TinyBase 官网](https://tinybase.org) — 反应式 API、Persister 与指南手册
4. [Electric 官网](https://electric-sql.com) — Shape 同步模型与部署文档
5. [Instant 官网](https://www.instantdb.com) — InstML Datalog 查询与 React SDK 文档
6. [Evolu 官网](https://www.evolu.dev) — 加密模型与自托管同步服务器说明
7. [Fireproof 官网](https://fireproof.storage) — 账本数据库设计与云连接方案
8. [dmotz/trystero 仓库](https://github.com/dmotz/trystero) — 信令策略列表与 API 示例

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
