Actual 介绍与选型指南

目标：面向准备在自有服务器上搭建个人记账系统的读者，系统梳理开源信封预算记账软件 Actual（通常称 Actual Budget）的产品定位、双形态架构、功能特性与选型考量，并与 Firefly III、YNAB、GnuCash 做量化对比。本文为认知溯源篇，全部事实均来自官方渠道联网取证（查询日期 2026-10-28），不包含本地实测内容；部署与运维实测见本专栏后续发布的实战篇目。

一、环境信息

本文是纯联网溯源的认知篇，以下列出取证对象与溯源环境，供读者核对信息时效：

• 溯源组件：Actual Budget，主仓库 github.com/actualbudget/actual，官网 actualbudget.com，官方文档站 actualbudget.org
• 溯源日期：2026-10-28
• 当前最新稳定版：v26.10.0（来源：GitHub Releases 页面 github.com/actualbudget/actual/releases，该页同时可见 v26.9.0、v26.8.1、v26.8.0、v26.7.0、v26.6.0、v26.5.2 等近期版本）
• 社区热度：主仓库星标约 30k（来源：shields.io 徽章数据 img.shields.io/github/stars/actualbudget/actual.json，实查返回 "message":"30k"）
• 官方文档安装章节：actualbudget.org/docs/install（客户端/服务端功能矩阵、各安装路径均以此页为权威）
• 历史发布仓库：github.com/actualbudget/releases 已于 2023-04-08 归档为只读（页面标注 "This repository was archived by the owner on Apr 8, 2023"），版本发布已迁移至主仓库 Releases 页——引旧链接的读者请注意改走主仓库

💡 说明：Actual 的版本号采用 v<年份两位>.<月份>.<补丁> 的日历化格式（如 v26.10.0 对应 2026 年 10 月版），与 Node.js、Ubuntu 等项目的日历版本风格一致；看到版本号即可判断新旧。

二、软件概述

Actual 是一个本地优先（local-first）的个人记账与信封预算软件，官网对其的概括是 "a super fast and privacy-focused app for managing your finances"（一款极快、注重隐私的个人财务管理应用），其核心是经过长期验证的 Envelope Budgeting（信封预算法）。

三个官方强调的关键词，基本概括了它的产品哲学：

1. You own your data（数据归你所有）：全部账目数据以本地预算文件形式保存，可自由导出、复制、备份，不锁定在任何厂商的服务器上。
2. Local-first（本地优先）：Actual 本质上是一个本地应用——应用完全在本地运行、离线可用，服务器只承担"后台同步"角色。官方原话："Actual is a local app, plain and simple. Your data is synced in the background so all devices have access, but the app totally works regardless of your network connection."
3. 端到端加密可选：官方文档明确提供可选的端到端加密（E2EE），开启后"your data remains unreadable, even to the server"——连自建服务器都无法读取账目明文。

项目沿革与许可：Actual 最初以订阅制托管服务形态存在，后来开源；官方安装文档中仍保留了 "If you're coming from the original, managed Actual subscription service, you may want to migrate your data"（如果你来自原有的托管订阅服务，可以迁移数据）的迁移指引，且 actualbudget/releases 独立发布仓库已于 2023-04 归档，可佐证项目已完全转向社区化开源维护。当前许可证为 MIT，由 Actual Budget 社区维护，官方文档与博客均挂在 actualbudget.org 域名下。

技术栈与双形态：

💡 说明：对自托管读者而言，"Actual 双形态"中最需要关注的实体是 sync-server（同步服务器）——桌面 App 与浏览器都只是客户端，真正需要部署、运维、备份的只有一个进程：sync-server 及其管理的预算文件目录。本专栏部署与运维各篇均围绕 sync-server 展开。

三、核心架构

理解 Actual 的架构，关键是理解"客户端本体 + 同步服务层"的分层，以及它与服务端中心化记账软件的本质差异。

3.1 官方功能矩阵：没有服务器能用什么，有了服务器多什么

官方安装文档给出了一张明确的客户端/服务端功能矩阵，是理解架构分工的第一手依据（逐行摘自 actualbudget.org/docs/install）：

解读：纯记账核心（预算、导入导出、报告）在客户端本地即可完成；服务器带来的是"多端使用 + 多端同步 + 银行同步 + API"这四类增值能力。这也解释了为什么官方把 sync-server 列为"不是必需、但强烈推荐"——对长期使用而言，没有同步层的 Actual 退化成了单机软件，数据只存在单一设备的浏览器存储或桌面文件里。

3.2 同步机制：本地文件为中心的消息式同步

Actual 的数据主权锚点是预算文件（budget file）：所有账目、分类、规则都存在一个预算数据库文件中。sync-server 管理用户身份与预算文件目录，客户端之间通过"记录变更 → 同步消息 → 各端重放"的分布式系统方式保持一致。官方对其同步层的表述是 "uses sophisticated distributed systems technology to sync changes across any number of devices"（使用成熟的分布式系统技术在任意数量设备间同步变更）。

由此形成的读写路径是：

• 写：任一客户端在本地修改账目 → 本地立即生效（离线也不阻塞）→ 变更消息异步推送到 sync-server → 分发给其他设备；
• 读：客户端启动时从本地预算文件直接渲染，网络只影响"新变更的到达速度"，不影响可用性。

💡 技术拓展：个人记账软件的"多设备数据一致性"有三条主流路线，直接决定了软件的数据主权与离线能力——

路线	原理/特点	代表	适用场景
服务端中心化	所有读写都打到云端数据库，无网不可用	YNAB（SaaS）	完全托管、不介意数据在厂商侧
local-first + 自托管同步层	本地文件为权威数据，服务器只转发/存储同步消息，离线完全可用	Actual	隐私敏感、自建 NAS、多端离线场景
纯单机文件	单一文件 + 手动复制/网盘，无自动同步	GnuCash	单机记账、不依赖网络

本文主角 Actual 采用第二条路线：local-first + 自托管 sync-server，这也是它区别于 Firefly III（中心化 Web 服务）与 YNAB（订阅制 SaaS）的根本架构差异；开启端到端加密后，服务器侧连预算文件明文都不可见。

3.3 数据目录与安全边界

从官方配置文档与安装文档可确认，sync-server 在服务器侧维护的关键数据是用户目录下的预算文件集合与用户上传文件目录——这一"目录即全部数据"的结构，直接决定了备份策略可以极简化（备份一个目录即可，详见本专栏运维篇的实测沉淀）。安全边界上有两层可选：

1. 登录密码：sync-server 的基础认证层，按预算文件校验访问密码；
2. 端到端加密（E2EE）：在客户端开启后，预算文件在加密形态下存于服务器，服务器仅承担密文转发——官方文档将其定位为 "next-level security" 选项，默认不启用。

四、功能特性

以下功能清单逐项溯源自官网首页（actualbudget.com）与官方文档，均为官方明示的交付能力：

• 信封预算（Envelope Budgeting）：官方强调 "You can only budget cash you have on hand"——只能把手头实际持有的现金分配到各个"信封"（分类预算），预算永远基于真实收入而非想象数字，这是与 YNAB 同源的零基预算方法论。
• 交易管理：流线化交易录入、转账双侧联动（创建转账交易后两侧自动关联、同步更新）、拆分交易。
• 交易导入：支持主流金融文件格式 QIF、OFX、QFX、CAMT.053 与 CSV（官网原文列举）。
• 银行同步：内置两条通道——GoCardless（覆盖欧盟/英国银行）与 SimpleFIN（覆盖美国/加拿大银行），需在服务器端配置（对应功能矩阵中"需服务器"行）。
• 报告：默认内置净值（Net Worth）与现金流（Cash Flow）报告，另有可自定义报告引擎（custom report engine）。
• 撤销与重做：官方表述为 "A robust undo system allows you to rollback any changes you make, and redo them if desired"——任意修改可回滚。
• 迁移导入器：内置 YNAB4 与 nYNAB（新版 YNAB）导入器，保留全部历史；社区另有更多导入器。
• 多设备同步与 PWA：自托管 sync-server 后，浏览器/桌面/移动端多端同步；Web 页面可安装到设备，移动端安装后可离线工作。
• API：官方提供 "fully-featured API"（全功能 API），供开发者编写自定义导入器或扩展功能；API 直接运行在本地数据之上，另有配套的 Node.js API 客户端库（@actual-app/api）。
• 暗色模式与主题：内置暗色模式，支持跟随系统默认的动态主题。

💡 说明：Actual 的功能面刻意聚焦在"个人/家庭预算"这一件事上，没有投资组合管理、多币种折算报表、发票应收应付这类企业化能力。如果需要这些，请直接看第六、七两章的选型建议。

五、快速开始（最小可用示例）

本章按"零安装体验 → 官方推荐自托管路径"的顺序给出最小可用示例，全部为官方文档记载的标准路径（本地逐条实测见本专栏部署篇）。

5.1 零安装：官方演示站

官方维护了公开演示环境，打开即用，用于零成本评估界面与预算方法：

• 演示站地址：https://demo.actualbudget.org/（来源：官网首页 "Try the demo" 与安装文档）

这是不落任何数据、不上服务器的体验路径，适合在决定自托管之前先确认"信封预算"方法是否合自己的使用习惯。

5.2 自托管路径一：Server CLI（官方推荐的手动路径）

官方安装文档 "Running a Server" 一节明确：愿意在终端执行几条命令的用户，可使用 Server CLI 以一条简单命令运行服务器（工具对应 NPM 包 @actual-app/sync-server，AUR 社区包 actual-server 的描述也注明其基于该 NPM 包并提供 systemd 单元文件）。最小形态如下（Node.js 环境就绪的前提下）：

# 用 npx 直接拉起 sync-server（包名 @actual-app/sync-server 已在官方文档与 AUR 包描述中确认）
npx @actual-app/sync-server

启动后按终端提示的监听地址用浏览器打开 Web 界面，设置预算文件密码、创建第一个预算文件即可开始记账。CLI 方式适合临时验证与个人单机使用；长期服务建议配合 systemd 或容器编排托管（社区 AUR 包即提供 systemd 单元）。

5.3 自托管路径二：官方 Docker 容器（生产自托管的主流路径）

官方安装文档明确提供 Docker 部署章节（"If you want to use Docker, we have instructions for using our provided Docker containers"），这是数据可持久化、便于升级回滚的自托管主流路径。其核心形态是：

• 官方提供现成的服务器容器（镜像内含 sync-server 与 Web 客户端静态资源）；
• 需要持久化的只有用户数据目录（预算文件、上传文件都在其中）；
• 通过环境变量调整监听地址、端口与数据目录位置。

官方 Compose 编排的具体字段、数据目录落位与逐条验证回显，属于本地实测范畴，详见本专栏《Actual Docker Compose 部署实战》篇——该篇基于官方 actual-server 镜像完成了从零起栈到记账同步的全流程实测。

5.4 初始化预算的三步动作（所有路径通用）

无论走哪条路径，服务起来后的首次初始化都是同样的三步：

1. 打开客户端：浏览器访问服务器地址（或桌面 App 填入服务器 URL）；
2. 设置预算文件密码：该密码同时是 sync-server 的登录凭据（开启 E2EE 后还参与加密）；
3. 新建预算文件 → 录入账户与交易：从空白预算或 YNAB 导入器开始，把银行账户余额建成账户、把每月支出建成分类信封。

💡 说明：桌面 App（GitHub Releases / Microsoft Store / Flathub 分发）既可以当纯单机客户端（完全离线），也可以"连接到自建服务器"从而获得同步、银行同步与 API 能力——"桌面 App 连自建 server"的多端验证正是本专栏运维篇的实测内容之一。

六、适用场景与限制

6.1 适用场景

结合官方定位与功能矩阵，Actual 最契合的场景按优先级排列：

1. 隐私敏感的多端个人/家庭记账：账目不出家门（可选 E2EE），同时在手机、电脑、浏览器间自动同步——这是 local-first 架构的直接收益；
2. YNAB 用户的自托管替代：官方内置 YNAB4/nYNAB 导入器、预算方法同源（信封/零基），且免去订阅费（YNAB 为订阅制付费产品）；
3. NAS / 家庭服务器生态：数据就是一个可备份的目录，备份策略极简，适合与家庭自托管服务共存；
4. 离线优先的记账：火车上、飞行模式下的记账本地立即落账，联网后自动同步；
5. 需要 API 做自动化的极客：全功能 API + Node.js 客户端库，可写脚本批量导入、对账、生成报表。

6.2 限制与不适用

官方渠道明示或可由架构直接推导的限制，选型前必须知悉：

• 银行同步不覆盖中国大陆银行：官方仅内置 GoCardless（EU/UK）与 SimpleFIN（US/Canada）两条通道，国内用户主要依赖 CSV/OFX/QIF 手动导入；
• 单用户密码体系：sync-server 的认证按"预算文件 + 密码"组织，没有多角色/多人协作权限模型，家庭共享预算靠共享密码而非账号体系；
• 非复式记账：Actual 面向个人现金流预算，不提供会计级复式记账与科目体系——需要严谨复式记账的应看 GnuCash / Ledger 系；
• 无服务器则能力受限：官方功能矩阵显示，不部署 sync-server 时移动端/浏览器/同步/API 均不可用，纯浏览器本地模式被官方标注为"不推荐长期使用"（存在浏览器清存储丢数据风险）；
• 托管渠道的地域依赖：官方推荐的 PikaPods/Fly.io 托管与演示站均在国内访问不稳定，国内用户以完全自托管为宜。

七、同类选型对比

个人记账/预算软件的选型，本质是在"预算方法论、数据主权、部署形态、成本"四个轴上做取舍。下表给出 Actual 与三款最具代表性同类产品的量化对比：Actual 各项数据均为本次溯源实查（查询日期 2026-10-28）；其余三款为公开资料层面的定性溯源，具体版本号以各自官方渠道为准。

关键差异解读与选型建议（"如果……则……"）：

• 如果你是 YNAB 用户、想保住信封预算方法但摆脱订阅与云端 → 直接选 Actual：方法论同源、官方迁移器保留全部历史、自托管后数据主权完整；
• 如果你需要会计级复式记账、科目余额表、多币种严谨核算 → 选 GnuCash，Actual 的简化模型不适合；Firefly III 居中；
• 如果你想要功能丰富的"个人财务管理系统"（规则、自动化、报表维度多）且习惯中心化 Web 应用 → 选 Firefly III；它没有信封预算与离线能力，换来的是更细的交易管控；
• 如果你的核心诉求是"数据永不出家门 + 多端同步 + 零费用" → Actual 是三者中唯一同时满足 local-first、自托管同步与 MIT 免费的；
• 如果你只有一台电脑、从不用手机记账 → GnuCash 更省事（免部署），Actual 的同步层此时是多余的。

💡 说明：表格中 Actual 之外的社区热度与费用数字会随时间变化，仅作量级参考；做最终决策前请以各产品官方仓库/定价页当日数据为准。

八、参考链接

以下为本篇全部事实来源（查询日期 2026-10-28）：

• Actual 官网：https://actualbudget.com/
• Actual 官方文档站：https://actualbudget.org/docs/
• 官方安装文档（功能矩阵与安装路径）：https://actualbudget.org/docs/install/
• 主仓库 Releases（版本取证）：https://github.com/actualbudget/actual/releases
• 主仓库星标徽章（热度取证）：https://img.shields.io/github/stars/actualbudget/actual.json
• 已归档的历史发布仓库（沿革佐证）：https://github.com/actualbudget/releases
• 官方演示站：https://demo.actualbudget.org/
• Flathub 桌面端分发：https://flathub.org/apps/com.actualbudget.actual