做衡仓时，我先解决的不是图表，而是数字为什么对不上

做资产工具，很容易先想到总资产曲线、收益率和漂亮的占比图。我在衡仓里更关心一个基础问题：点进明细后，还能不能解释总览上的数字？

如果总览按一套规则汇总，持仓页按另一套规则计算，即使每个页面单独看都合理，放在一起也可能对不上。跨账户、跨币种后，差异更难解释。这是设计时需要防住的问题，不是已经发生过的用户事故统计。

先把一笔钱怎么算说清楚

例如，一笔现金转成了证券持仓。如果把现金的旧余额和新持仓市值都加进总资产，同一笔钱就可能被算两次。要避免这种问题，先得明确现金如何从期初余额和流水得到，持仓按什么价格计值，再决定两者怎样合并。

币种也一样。没有汇率时，不能把 100 元和 100 美元直接加成一个“200”。页面应该保留分币种结果，并让缺少换算依据的状态可见。这里的数字只是解释口径的例子，不是产品里的真实资产。

衡仓的做法，是让 FastAPI 服务在同一个数据库读事务里获取账户、持仓、流水和目标，形成账本快照。Android 和 Web 读取这份结果，金额在服务端用 Decimal 处理。

这样做把责任集中到一个地方：如果数字不对，先沿账本汇总链路找原因，而不是同时猜测两个客户端各自做了什么。代价是客户端展示能力和服务端接口需要一起维护；一份快照也不会自动解决错误行情或缺失汇率。

三桶展示放在这之后。进取、稳健、防守的占比只有建立在可解释的总额上，才适合拿来与目标比较。产品展示的是结构和偏离，不替使用者决定投资操作。

我希望访客不注册就能试用，所以 Web 示例模式在浏览器内存中提供虚构账本，刷新后恢复。它不调用真实账本接口，截图导入使用预先准备的示例图片与结果。

这降低了试用门槛，也带来一项额外工作：浏览器内的示例计算是否和服务端一致？2026-10-14 的本机记录中，用服务端账本函数对照了 6,000 条随机持仓及示例账本两个月的汇总，没有发现不一致；当次浏览器验收也核对了示例流程不请求 /api。

这是一个有边界的结果。它不代表所有真实资产都已核对，也不代表实时行情、完整登录和真机流程已经验收。本次写作没有重跑这些检查，详细日期与限制保留在产品开发记录。

先定义口径，再集中计算，然后验证客户端是否读对，最后才选择图表。界面帮助人理解账本；账本本身仍需要能被解释和核对。

试用虚构账本，可以先看总览，再进入持仓和流水。自己的账本需要注册登录。