rotki 评测：本地加密资产记账，隐私优先但门槛不低
保护您隐私的投资组合跟踪、分析、会计和管理应用程序。
秒懂
- 它是什么？
- rotki 是一款自托管的加密货币投资组合管理工具，强调数据本地加密存储，以 AGPL-3.0 开源。本文基于其 README 与发布信息，分析其机制、安装路径与适用边界。
- 适合谁用？
- rotki 适合那些不愿意把交易所 API 密钥或链上地址交给第三方 SaaS 的用户，尤其是需要年度 PnL 报税数据的个人或小型机构。不适合对易用性要求极高、不愿接触命令行或 Docker 的人，也不适合需要团队协作或多用户权限管理的场景，因为其定位是单机自托管。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：把财务数据从云端手里夺回来
市面上的加密资产追踪工具大多是闭源 SaaS，用户必须把交易所 API 密钥、钱包地址甚至交易历史上传到别人的服务器。rotki 的立场很直接：数据加密后留在本地，用户自己保管。它面向的是对数据主权敏感的加密资产持有者，尤其是需要做税务申报或年度盈亏分析的人。README 明确说，它的使命是提供一个“self-sovereign alternative”，而不是又一个云端仪表盘。这个定位意味着它不追求零门槛，而是把控制权放在第一位。
核心机制：本地加密存储加交易解码
rotki 的工作方式可以从其功能列表反推出来。它通过导入交易所数据、区块链地址和交易历史，在本地进行交易解码，也就是把原始的链上事件和交易所记录转成可读的收支明细。解码后的数据用于生成投资组合总览、历史图表和 PnL 报告。关键点是，所有数据在本地处理，加密存储，不上传。这个架构与云端工具的根本区别在于，你的 API 密钥和地址簿不会离开你的机器。但 README 没有详细说明加密算法的具体实现，也没有提及密钥管理方式，这部分需要查阅文档才能确认。
安装与运行：二进制包是首选，源码构建有硬性要求
对于普通用户，rotki 推荐直接下载预打包的二进制文件，支持 Windows、macOS 和 Linux。这是最省事的路径。如果你想从源码构建，README 列出了四项硬性依赖：Node.js、npm、Python 3.14 和 uv 包管理器，另外还提到 Docker，但未说明 Docker 在构建中的具体角色。源码构建显然面向开发者或需要定制的人。一个值得注意的点是 Python 3.14 的要求相当新，如果你的系统默认 Python 版本较低，需要先解决版本问题。安装后，按照文档配置设置并导入地址即可开始使用。
功能边界：分析强，但协作与多用户是空白
rotki 的功能集中在单用户场景：组合跟踪、图形化历史数据、交易解码、UI 定制和 PnL 报告。它没有提及任何多用户、权限管理或团队协作功能，也没有云同步选项。这意味着如果你有多个设备或需要让会计师远程访问数据，rotki 的本地单机模式会成为障碍。另一个限制是，它依赖用户手动导入地址和配置交易所连接，如果你有大量历史交易且来源分散，初始导入会相当耗时。README 提到的 Pro 版本和集成页面暗示某些高级功能可能需要付费订阅，但具体哪些功能被锁定在免费版之外，README 没有明说。
替代方案：云端 SaaS 与自托管记账工具的分野
与 rotki 形成直接对比的是 CoinTracking 或 Koinly 这类云端服务。它们的做法是你把交易所 API 密钥交给它们，由它们在服务器上拉取数据并生成税务报告。优点是零安装、界面友好、支持多用户协作，但代价是你的财务数据完全暴露给第三方。rotki 把数据留在本地，但你要自己承担安装、升级和备份的责任。另一个替代方向是使用通用的自托管记账软件如 Firefly III，但它并非为加密资产设计，缺乏交易解码和链上数据支持。rotki 的独特之处在于它把隐私保护和加密资产专用功能结合在同一个本地应用中，这是通用记账工具做不到的。
维护与升级：活跃发布，但 AGPL 许可有商业约束
从发布历史看，rotki 保持着稳定的更新节奏，v1.44.0 于 2026 年 8 月发布，此前有 v1.43.2 和 v1.43.1，间隔约一个月到两个月。这说明项目维护活跃，但升级频率也意味着你需要定期跟进，否则可能错过漏洞修复或新链支持。许可方面，rotki 采用 AGPL-3.0，这是一个强 copyleft 许可证。如果你只是个人使用，没有任何义务。但如果你把 rotki 或其代码嵌入到商业产品中，或者提供托管服务，AGPL 会要求你开源整个衍生作品。README 明确提到可以提供商业许可作为替代，但需要联系官方洽谈。这不是法律建议，但采用前必须评估你的使用场景是否会触发 AGPL 义务。
编辑结论
rotki 适合那些不愿意把交易所 API 密钥或链上地址交给第三方 SaaS 的用户，尤其是需要年度 PnL 报税数据的个人或小型机构。不适合对易用性要求极高、不愿接触命令行或 Docker 的人，也不适合需要团队协作或多用户权限管理的场景，因为其定位是单机自托管。采用前应先验证三件事：确认你的 Python 版本与 uv 环境能否满足构建要求，检查 rotki 是否支持你使用的交易所或链的导入格式，以及评估 AGPL-3.0 对你是否构成义务，若你计划将其嵌入商业服务，需联系 rotki 获取商业许可。rotki 的隐私承诺以本地加密存储为根基，但这份承诺的兑现程度取决于你能否独立完成构建与维护。
社区笔记