计息与限额：算得清才能管得住

计息口径和限额控制是银行账务的两道闸门，算不清就管不住，管不住就出风险。拆开来看它们各自的关键点。

银行系统里最容易「看起来很简单、做起来全是坑」的两件事：计息和限额。它们一个决定「钱怎么生钱」，一个决定「钱不能出什么事」。两者共同的特点是：规则必须可被验证，结果必须可被复核。

计息：口径比公式重要

公式 本金 × 利率 × 天数 / 基数 人人会写，难的是口径统一。

计息基数：是每日余额、还是日均余额？贷款多用实际天数，存款各有约定。
闰年与节假日：一年按 365 还是 360？结息日遇节假日顺延还是提前？
利率变动：固定利率、浮动利率重定价日如何衔接，分段计息怎么切。

BigDecimal interest = dailyBalance
        .multiply(rate)
        .multiply(BigDecimal.valueOf(days))
        .divide(BigDecimal.valueOf(360), 6, RoundingMode.HALF_UP);

计息 bug 最可怕的结局，不是算错一笔，而是「每天错一点点，半年后对不上，却找不到从哪天开始错」。所以计息必须有可复现的逐日明细。

限额：控制点要前置

限额分好几类：单笔、日累计、月累计、余额上限、渠道限额。关键不在「存一个上限数字」，而在控制点必须前置到交易校验环节，而不是事后统计。

限额类型	控制点	典型场景
单笔限额	交易发起前	防单笔大额盗刷
日累计	交易前累计判断	渠道风控
余额上限	入账后校验	产品合规约束

限额规则要可配置，且变更留痕、可追溯生效时间。
累计类限额必须考虑并发：用原子计数或数据库约束，别靠「先查后扣」。
超限处理要明确：拒绝、转人工、还是降级，不能悄悄放行。

if (dailyUsed.add(amount).compareTo(dayLimit) > 0) {
    throw new LimitExceededException(cardNo, dailyUsed, dayLimit);
}

限额系统宁可「误杀一笔正常交易」，也不能「放过一笔该拦的」。前者是体验问题，后者是风险事件。

把计息的逐日明细和限额的前置校验都做扎实，核心账务才谈得上「算得清、管得住」。