金融系统

财务系统

财务相关的系统有什么注意点

一、金额表示与精度（最基础，出错最多）

禁止用 float/double 表示金额。0.1 + 0.2 != 0.3 这类精度问题在财务场景不可接受。Java 用 BigDecimal，数据库用 DECIMAL（如 DECIMAL(20,2)），不用 FLOAT/DOUBLE。
统一金额单位。要么全用"分"（整数存储），要么全用"元"（decimal 存储），在系统边界统一换算，禁止混用。
明确舍入规则。ROUND_HALF_UP（四舍五入）、截断、还是银行家舍入？必须在全局配置中定义，所有计算走同一个工具类，禁止各处自行 BigDecimal.setScale 散落实现。
运算顺序敏感。先乘后加、先舍入后求和 vs 先求和后舍入，结果可能不同（如折扣分摊、税额计算）。要明确"每笔明细舍入、汇总再舍入一次"的规则。

二、事务与一致性（账务核心）

所有资金变动必须在同一个数据库事务内完成，ACID 的原子性、隔离性、持久性不能打折。跨服务转账场景用"本地消息表 + 定时任务补偿"或分布式事务框架（Seata / Saga），不能裸奔。
复式记账：涉及资金变动的核心操作走借贷分录，保证"有借必有贷、借贷必相等"，这是账目自洽的根基。
余额类数据避免"读-改-写"：扣款、加款必须用 UPDATE ... SET balance = balance - ? WHERE balance >= ? 这类原子 SQL 或数据库行锁，防止并发超扣导致余额为负。

-- 防超扣：条件更新，返回影响行数为 0 则拒绝
UPDATE account SET balance = balance - #{amount}
 WHERE id = #{accountId} AND balance >= #{amount};

三、幂等性（防重复扣款/重复入账）

这是财务系统最致命的坑，重复扣款一次就可能出事故：

每笔交易必须有全局唯一业务号（如订单号），并在数据库建唯一索引兜底。
入账/出账接口必须支持幂等：同一业务号重复请求只生效一次，第二次直接返回原结果。
外部回调（如支付渠道 webhook）天然会重试，必须在接入层做去重。

四、审计留痕与可追溯（财务合规底线）

资金变动不可覆盖、不可物理删除。做错账用"冲销/红字分录"纠正，保留原记录。
每次变更记录操作人、时间、操作类型、变更前后值（before/after），可用数据库 BEFORE UPDATE 触发器或审计字段统一记录。
记账、审核、复核角色分离（不相容职责分离 SoD）：操作人不能审核自己的单子。
时间统一：所有记账时间用服务端时间，明确时区（涉及跨天结算时，日切点要精确定义，避免"今天 23:59 和明天 00:01 账对不上"）。

五、对账机制（系统严谨性的最后防线）

内部对账：明细账 ↔ 总账 ↔ 余额，定时自动核对，不平即告警。
外部对账：与支付渠道/银行每日流水对账（T+1），差异（长款、短款、状态不一致）进对账差异表，人工或自动处理。
报表数据不能直接查流水，应基于最终确认的状态汇总，避免"查询时数据还在变"。

六、并发与状态机

单据/交易定义明确的状态机（如：待支付 → 支付成功 → 已退款 / 支付失败），非法流转直接拒绝，防止"已退款还能再退"。
对账、结算、报表的跑批任务要与在线交易互斥（批内锁、版本号），避免半截数据。

七、安全与合规

敏感字段（身份证、银行卡号）加密存储、脱敏展示；密钥管理走 KMS。
权限按角色最小化授权，高危操作（改账、冲正、退款）二次确认 + 强审计。
了解当地会计/税务基本要求（如中国《会计法》、凭证保管年限），发票、凭证、报表留存完整。

八、测试与演练（"严谨"靠测试兜底）

金额计算全部有单元测试：边界值（0、负数、超大额、最小单位 0.01）、舍入、并发扣款。
并发测试：多线程同时扣同一账户，验证余额不为负、不丢失更新。
幂等测试：同一业务号重放 N 次，结果一致。
对账演练：故意制造"账不平"，验证告警和差异处理流程能跑通。
故障演练：渠道超时、服务重启、重复回调时，账务是否还能收敛到正确结果。

一句话总结

严谨性 = 金额精度 + 事务一致性 + 幂等 + 留痕不可删 + 权限分离 + 对账兜底 + 测试覆盖。核心心法："任何一笔钱的变动，都必须能回答出『谁、何时、为何、前后是什么、是否唯一执行、是否可追溯、账是否平』这七个问题。"

如果你接下来要在当前 Java 项目（Java 8 / Maven）里引入财务功能，我可以帮你搭一个包含 Money 金额工具类、幂等表、审计字段的骨架；另外如果想深入某个点（比如对账设计、分布式事务方案），告诉我具体场景，我展开细说。