2026 年自托管 Mint 替代方案：把预算数据掌握在自己手里
正在寻找自托管 Mint 替代方案？看清不同方案的取舍，安全映射旧交易，并搭建一套可核查、可迁移的预算系统。
Intuit 的 Mint 当前页面会把想继续使用熟悉功能的 Mint 用户引导至 Credit Karma。这是一条托管服务路线，却没有回答许多有技术背景的前 Mint 用户更关心的问题：多年积累的预算数据接下来该存在哪里？怎样迁移，才不会悄悄改变账户余额？
如果比起自动连接银行，你更看重数据所有权、可核查的账本和经过审慎控制的导入流程，那么 Expense Budget Tracker 是一个可靠的自托管 Mint 替代方案。它不是拿来即用的 Mint 克隆版：既不会自动连接银行，也不会与 Mint 同步。你需要逐笔记录交易，或者导入自己保留下来的数据，再核查结果。
这正是选择时需要权衡的核心。如果你希望账户无需自己操作就能自动更新，请选择以银行数据聚合为核心的产品。如果你想让财务系统运行在自己的 Postgres 数据库上，能够逐行检查数据，并按自己的方式实现自动化，那么这条路线更合适。
简短结论：在数据掌控权和自动化便利之间做选择
| 你最看重什么 | 更合适的方向 | 原因 |
|---|---|---|
| 自动连接银行，日常几乎不用操作 | 托管式聚合工具 | Expense Budget Tracker 不会自动同步银行数据 |
| 本地或自托管数据库 | Expense Budget Tracker | Docker Compose 配置会在你掌控的基础设施上运行 Web 应用和 Postgres |
| 无需自行运维服务器的应用 | 托管版 Expense Budget Tracker | 无需本地配置，即可使用托管的账本和预算功能 |
| 可核查的余额和转账 | Expense Budget Tracker | 账户余额由账本记录求和得出，转账也保留为明确的账本变动 |
| 一键复现 Mint 的所有旧功能 | 不能预设任何方案都能做到 | 迁移全部历史记录前，先测试你实际用过的工作流 |
正因如此，开源 Mint 替代方案未必适合所有人。自托管带来掌控权，也意味着升级、备份、安全和恢复都要由你负责。自托管指南从 Docker Compose 入门配置讲起，也介绍了面向生产环境的 AWS 部署方案。
先了解数据将迁入什么系统
安全迁移应该从理解目标数据模型开始，而不是先盯着 CSV 的各个字段。
Expense Budget Tracker 将财务数据存储在 Postgres 中。它的 accounts 视图由账本记录推导而来，并非单独维护的一张余额表。每条账本记录都包含账户、带符号金额和账户原币，类型则是 income、spend 或 transfer 三者之一。
这样做有一个实际好处：仪表盘数字不对时，你无法直接覆盖当前余额，因为余额是账本中所有变动的总和。导入错误因此始终看得见，也能修正；但反过来，漏掉的期初余额也不会凭空出现。
预算是独立的一层。基础计划记录每个月、每个类别的计划金额；后续调整单独存储，再汇总成最终生效的计划。实际收入和支出仍然来自账本。先迁移交易，再重建未来预算，可以避免两项工作相互干扰。
在多币种场景中，每条记录都会保留账户原币。工作区设有一种报表币种，读取报表时再按每日汇率换算。请先用每个账户的原币完成核对。仪表盘中的换算总额只是报表结果，不是银行提供的原始余额。
导入第一行数据前，先做好映射
如果你保留了 Mint 导出文件，请在副本上操作，原文件不要改动。如果没有保留，就使用你能核实的时间段内的银行和信用卡账单。不要假定现在仍能导出 Mint 数据，也不要把日期范围重叠的 Mint 导出文件和账单同时作为写入来源。
在让代理或脚本获得写入权限前，先写下映射规则：
| 来源概念 | Expense Budget Tracker 中的目标 | 需要做出的决定 |
|---|---|---|
| Mint 账户 | 账本记录使用的稳定 account_id |
为每个真实账户选定一个 ID 和账户原币；导入中途不要更改该 ID |
| 交易 | ledger_entries 中的一行 |
统一日期、带符号金额、币种，以及 income 或 spend 类型 |
| 商户或收款方 | counterparty |
应用任何清理规则前，先保留原始文本 |
| 备注 | note |
保留有用的上下文；不要把备注变成类别 |
| 类别和子类别 | category |
保留旧结构，或定义一份明确的映射表 |
| 自有账户之间的转账 | 共享同一个 event_id 的两行账本记录 |
使用 kind = transfer；转出账户记负数，转入账户记正数 |
| 来源交易 ID | external_id 或导入清单 |
保留稳定标识符，确保再次运行时能找到同一条来源记录 |
| 旧预算目标 | 核对完成后重新创建的基础预算计划 | 只迁移你仍在使用的计划；不要根据交易总额推断旧预算 |
| 后续计划变更 | 预算调整 | 保留原始基础计划，并单独记录变更 |
迁移时很容易让人想顺手整理类别，但这样会把一次可控的迁移变成几个项目同时推进。试点阶段先保留旧类别，等余额完全一致后再合并或重命名。
先确定“期初余额”的含义
账户和余额都来自账本，因此必须先做出这个决定，才能确定导入范围。
导入完整历史记录
如果保留的数据从账户最初启用时就开始，而且历史记录完整，就导入完整账本。最终余额应该由这些记录自然得出，无需人工补一条起始记录。
这是最干净的方案，通常也是最慢的方案。时间跨度很长的导出文件可能包含重复记录、改过名称的账户、已删除的类别，以及已经看不出配对关系的转账记录。
从一个清晰的切换日期开始
对大多数迁移来说，一个已结束的账单周期更适合作为试点。选择该账单的期初日期，并记录这个时间点的来源余额。
Expense Budget Tracker 没有单独的期初余额字段或账本类型。如果你需要它从第一天起就显示真实余额，可以在第一笔导入交易之前人为补入一条标记清楚的账本记录。资产的正余额可以记为一条正数 income；信用卡或负债的负余额可以记为一条负数 spend。
只要报表的日期范围包含这一天，该记录仍会计入收入或支出。把它紧挨着放在切换点之前，使用 Opening balance 之类的类别，在备注中写明来源账单和日期，并从切换点之后开始分析正常收入和支出。清楚的标签能让这条过渡记录便于审计，却不会自动将它排除在报表之外。如果切换点之前的报表也必须准确，导入完整历史记录才是更安全的数据模型。
只追踪新增交易
你可以跳过历史余额，只从新交易开始记录。但这样一来，追踪器中的账户余额就不完整。这个选择适合从某个日期开始按类别追踪；如果你希望“账户”视图与今天的银行余额一致，它就行不通。
分阶段迁移 Mint 数据，确保余额准确
最实用的迁移单元，是一个账户的一个已结束账单周期。这个范围足够小，便于检查；也足够大，能够暴露退款、重复记录和金额符号错误。如果该账户与另一个也要追踪的账户之间存在转账，请同时纳入配对账户对应周期的账单，或者换一个更简单的试点。只看转账的一侧，无法完整核实内部转账。
1. 保留原始资料并建立清单
把保留的 Mint 文件、账单文件和所有类别映射放在用于导入的工作副本之外。为每个账户列出以下信息：
- 稳定的目标 ID
- 账户原币
- 可用交易的最早和最晚日期
- 试点周期的期初和期末余额
- 是否包含与范围内另一个账户之间的转账
如果已归档或关闭账户的历史记录也要迁移，它们仍然需要稳定的 ID。
2. 新建干净的工作区并选择报表币种
使用一个可随时丢弃的本地 Docker 部署，或单独的托管工作区来测试迁移。设置报表币种，但核对表仍应使用每个账户的原币。
由于“账户”视图由账本记录推导，账户会在写入第一条记录后出现。根据前面的选择，第一行可以是有据可查的期初余额，也可以是第一笔真实交易。
3. 制定一条统一的去重规则
如果保留的数据中有来源交易 ID，就把它用作 external_id。数据库不会为该字段强制执行唯一性约束，因此再次运行时，写入前仍必须查询目标系统，确认是否已经存在账户和来源 ID 都相同的记录。如果来源没有 ID，请根据稳定字段生成确定性的导入键，例如账户 ID、入账日期、带符号金额、币种和未经修改的来源描述。把这个键保存在导入清单中，并在写入每个批次前，将候选记录与目标系统中的现有记录进行比较。
不要只用 event_id 作为转账的去重键。同一笔转账的两侧本来就会共享同一个事件 ID。
如果保留的 Mint 导出文件和银行账单存在重叠，请选择其中一个作为写入来源，另一个只用来核对记录数和余额。
4. 先做一次不写入数据的试运行
插入任何数据前，先把第一批记录解析成审核表。表中应包含：
- 来源行标识符
- 目标账户 ID
- 入账时间戳
- 带符号的原币金额和币种
- 拟定类型
- 拟定类别
- 交易对手与备注
- 如果涉及转账，列出配对账户和两侧的带符号金额
十条普通记录再加几条复杂记录，比第一次就尝试一千行更有价值。如果该周期内有退款、转账和重复出现的商户，请把它们都纳入试运行。
如果金额符号或账户映射存在歧义，就在这里停下。此时靠猜测写入，之后就得靠余额修正来补救。
5. 插入一小批数据
只写入试点账户中已经审核过的记录，以及内部转账中已经确认的配对记录。写入后立即在交易视图中检查，寻找金额符号颠倒、时区导致的日期偏移、分币丢失、币种错误，以及描述清理过度、无法追溯到来源等问题。
在两个自有账户之间转账时，要创建两条事件 ID 相同的记录。从支票账户向储蓄账户转账 500 USD，应在支票账户中记录一笔 -500 USD 的 transfer，在储蓄账户中记录一笔 +500 USD 的 transfer。不能把一侧记作支出、另一侧记作收入。跨币种转账时，请使用两侧各自实际入账的金额和账户原币，不要根据一侧反推另一侧。
信用卡还款也遵循同一规则。信用卡上的原始消费才是支出；之后的还款是从支票账户到信用卡账户的转账。如果再把还款计作支出，当月支出就会被重复计算。
6. 核对无误后，再导入下一批
对于该批次涉及的每个账户，都要用账户原币验证下面的等式：
期初余额 + 已入账交易的带符号金额 = 期末余额
请与已结束的账单对比，不要拿包含待处理交易的可用余额来比。然后检查：
- 源数据行数和已导入行数
- 每一条疑似重复记录
- 每一对转账在两个账户中的记录
- 退款和冲正
- 准确的期末余额
如果余额不对，就停下来，找出缺失、重复或金额符号错误的记录。不要为了让总额看起来正常，就添加一条无法解释的修正记录。预算与银行余额核对指南提供了更完整的逐账户检查清单。
7. 每次只扩展一个边界
一个周期核对一致后，再添加同一账户的下一个周期。继续下一个周期前，先补全并核对每一笔内部转账的两侧记录。完成这些工作后，才能迁移另一个账户。
这听起来比一次性批量上传更慢，但比在多个账户、横跨数年的混合数据中寻找一笔重复转账快得多。
如何把银行账单导入支出管理工具介绍了实际的账单处理流程。无论输入是保留的 Mint CSV 还是银行导出文件，步骤都一样：解析、映射、审核、写入和核对。
8. 确认账本可信后再重建预算
不要在尚未完成核对的交易之上建立一份精细预算。
实际交易数据核对一致后，重新创建本月和未来月份的基础计划。后续变化应通过预算调整来记录，不要改写最初的基础计划，这样才能保留当初的规划依据。然后将实际收入和支出与计划对比，并查看报表币种视图。
对于多币种家庭，账户用原币核对时可以完全一致，但按报表币种换算后的价值仍会随每日汇率变化。这种变动属于预期现象。不要为了让换算总额保持不变而改写来源金额。
导入时该用 MCP 还是 Agent API？
托管版产品目前提供两套相互独立、面向机器的接口。它们能处理相似的任务，但身份验证方式和凭据各不相同。
客户端支持时，使用托管 MCP 连接器
将支持 OAuth 的远程 MCP 客户端连接到 https://mcp.expense-budget-tracker.com/mcp。必需的 expenses:read 权限范围涵盖工作区发现、schema 检查和查询。只有客户端确实需要修改数据时，才申请可选的 expenses:write 权限范围。
这为迁移提供了一道实用的安全边界：先用读取权限检查 schema 和现有记录，再为已经审核的批次批准写入权限。MCP 连接器指南介绍了连接方式和工具流程。
终端代理或直接调用 HTTP 时，使用 Agent API
从 GET https://api.expense-budget-tracker.com/v1/ 开始。服务发现响应会引导代理完成邮箱验证、工作区选择和 schema 检查，并使用受限的 SQL 端点。经过身份验证的请求使用长期有效的 ApiKey。
Agent API 设置指南是最简短的入门路径，API 参考则介绍了读写端点。要求代理在写入前展示拟定的映射和确切批次，写入后再查询新增记录和余额。
MCP OAuth 令牌与 Agent API 密钥是两种独立凭据，既不能互换，也不应粘贴到文章备注、提示词或源文件中。
基础的本地 Docker Compose 配置会启动 Postgres、数据库迁移、Web 应用、身份验证服务和汇率 worker，但不会在本地启动 MCP 或 Agent API 服务。上述 URL 属于托管服务。如果你希望自行运行完整技术栈，文档中的生产环境 AWS 部署包含相应的 API 和 MCP 基础设施。
这款开源 Mint 替代方案适合谁
如果你需要以下能力，Expense Budget Tracker 会比较合适：
- 以 Postgres 作为唯一可信的数据源
- 可以选择托管版或自行部署
- 余额由可检查的账本变动推导而来
- 明确记录收入、支出和转账
- 保留账户原币记录，并按每日汇率生成报表
- 使用基础计划和可追踪调整的预算
- 为脚本和 AI 代理提供受控访问
如果自动连接银行是你的首要需求，或者你希望用一次无人值守的上传完成迁移，又或者你不想承担自托管服务的运维和备份工作，它就不合适。
自托管也不会自动保证每个接入工具的私密性。如果你把账单交给外部 AI 客户端，或授权它读取财务数据，该客户端及其模型提供商就会成为数据流转链路的一部分。请审查它们的政策，并只授予完成任务所需的最低权限。
如果你还在比较不同模式，而不是具体产品，无需连接银行的预算应用解释了主动导入的取舍。开发者也可以阅读更全面的面向开发者的自托管开源预算管理工具指南。如果你的旧系统更接近桌面会计软件，Quicken 替代方案指南采用了同样的单账户迁移测试。
常见问题
Expense Budget Tracker 可以直接替代 Mint 吗？
不能直接替代。它涵盖账户、账本记录、预算、转账、多币种报表、托管应用和自托管，但不会复现 Mint 的后台银行数据聚合，也不提供实时 Mint 连接。
它能导入 Mint 导出文件吗？
它没有一键式 Mint 导入器。如果你保留了导出文件，可以用脚本或已连接的代理将每一行映射到账本中。请先审核一小批数据并完成核对，再逐步扩展。如果没有保留导出文件，请使用银行和信用卡账单，迁移你能够独立核实的历史记录。
我能只在自己的电脑上运行它吗？
可以。Docker Compose 自托管配置可以在本机启动核心应用和 Postgres。之后，备份、更新、访问控制和恢复都要由你负责。
我应该迁移历年所有数据吗？
只有在历史记录完整且仍有用时才值得这样做。与其导入多年残缺的数据，不如从一个清晰的切换点开始，并记录有据可查的期初余额，这样可能更安全。请有意识地选择边界，并保持旧来源归档不变。
最安全的首次测试是什么？
使用一个账户、一个已结束的账单周期和一个主要来源文件。如果该周期包含内部转账，请同时纳入配对账户的账单，或者选择没有此类转账的账户。导入一小批经过审核的数据，并验证所有受影响账户的期末余额。确认无误后，再逐步扩展。