金融系统偏爱long而非int，因其取值范围更大（-922亿亿至+922亿亿），可安全存储以“分”为单位的巨额金额、64位订单ID及毫秒时间戳，避免int溢出；数据库应映射为BIGINT，配合Math.addExact()防溢出，小数运算仍需BigDecimal。
在金融领域，long 主要用于精确表示大整数金额、交易序号、时间戳等关键字段，核心目标是避免因数据类型容量不足导致的截断、溢出或精度丢失。
为什么金融系统偏爱 long 而非 int
标准 int 类型最大值为 2,147,483,647（约 21 亿），而一笔高频交易系统的日订单量可能轻松突破千万级；单个账户累计交易金额若以“分”为单位（避免浮点误差），动辄达百亿甚至千亿分（即十亿至百亿元），远超 int 表示范围。使用 long（取值范围：-9,223,372,036,854,775,808 到 9,223,372,036,854,775,807）可安全容纳这类数值，无需频繁拆分或引入复杂类型。
- 账户余额、交易金额统一以“分”存储（如 100.50 元 → 10050 分），全程用 long 运算，杜绝 float/double 的舍入误差
- 订单 ID、流水号采用自增或雪花算法生成，64 位 ID 天然适配 long，保障全局唯一且可排序
- 毫秒级时间戳（如 System.currentTimeMillis()）本身就是 long，直接用于交易对账、风控时效判断
数据库端对应的是 BIGINT
Java 中的 long 在主流关系型数据库（MySQL、PostgreSQL、Oracle）中应映射为 BIGINT 类型，而非 VARCHAR 或 DECIMAL（除非涉及小数运算）。BIGINT 是 64 位有符号整数，与 Java long 完全兼容，支持高效索引、范围查询和聚合计算。
- 建表时明确声明：
COLUMN amount BIGINT NOT NULL，而非 INT 或 TEXT - 避免使用 DECIMAL(19,0) 替代 BIGINT——虽语义等价，但存储开销略高、运算性能稍低
- ORM 框架（如 MyBatis、Hibernate）需配置字段类型映射，确保 long 字段正确绑定到 BIGINT 列
需要注意的边界问题
long 并非万能，它只解决整数范围问题，不处理小数精度或溢出防护。
- 加减乘除运算可能静默溢出（如 Long.MAX_VALUE + 1 得到负数），金融核心逻辑中建议配合
Math.addExact()等方法主动抛异常 - 涉及利率、汇率、手续费率等带小数的计算，仍需用 BigDecimal，不能仅靠 long
- 跨系统交互（如对接支付网关）时，确认对方是否也用 64 位整数传金额，避免因平台差异（如某些旧系统用 int）导致高位截断
实际落地建议
在新建金融模块时，可按以下原则选型：
- 所有金额字段（单位：分）、ID、时间戳、计数器，默认使用 long + BIGINT
- 对外 API 返回金额字段，JSON 中保持为数字（非字符串），前端 JavaScript 需注意 Number.MAX_SAFE_INTEGER 限制，必要时转字符串传输
- 存量系统升级时，检查历史数据是否已超出 int 范围，迁移前做数据校验与扩容测试
