java中处理金额必须使用bigdecimal，因其可精确表示十进制货币值；禁用double（二进制浮点误差）和long（单位耦合风险）；须用string构造、显式指定舍入模式、配合数据库精度配置及业务校验。
Java 中处理金额的高精度包装，**不推荐用基本包装类（如 Integer、Long）或浮点型包装类（Float、Double）**，因为它们无法准确表示货币值，存在精度丢失和舍入误差。资产管理系统对金额的准确性、一致性、可审计性要求极高，必须使用 BigDecimal —— 它是 Java 提供的、专为高精度十进制计算设计的不可变类。
为什么不能用 Double 或 Long 包装金额？
• Double 采用二进制浮点数表示，0.1 + 0.2 ≠ 0.3（实际为 0.30000000000000004），在资产折旧、摊销、多币种换算等场景会导致累计误差；
• Long 虽无精度问题，但只能表示整数分（如以“分”为单位），强制业务逻辑与存储单位耦合，易引发单位混淆（比如误将“元”当“分”入库）、前端展示复杂、汇率计算易出错。
用 BigDecimal 正确封装金额字段
• 始终通过 String 构造器创建 BigDecimal 实例，避免 double 构造器引入隐式精度污染：
❌ 错误： new BigDecimal(19.99) → 实际可能是 19.989999999999998
✅ 正确： new BigDecimal("19.99")
• 在实体类中将金额字段声明为 BigDecimal，而非其包装类（BigDecimal 本身已是引用类型，无需再“包装”）；
• 配合 JPA/Hibernate 使用时，建议配合 @Column(precision = 19, scale = 2) 明确数据库列精度（如支持小数点后两位），并配置 @Convert(converter = MonetaryAmountConverter.class) 统一处理序列化/反序列化逻辑。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
金额运算必须指定 MathContext 或 RoundingMode
• 加减法（add/subtract）天然精确，但乘除（multiply/divide）必须显式指定舍入规则，否则可能抛出 ArithmeticException（如除不尽）；
• 资产管理系统常用策略：
– 金额加总、账面余额：用 RoundingMode.HALF_UP（四舍五入）
– 折旧计算、摊销分摊：按会计准则要求，可能需 RoundingMode.HALF_EVEN（银行家舍入）避免系统性偏差
– 示例：amount.multiply(rate, new MathContext(10, RoundingMode.HALF_UP))
统一金额工具类与业务约束
• 封装常用操作为静态方法，强制规范用法：
– of(String)：安全构造，自动 trim 并校验格式
– zero() / one()：预设常量，避免重复 new
– compareToZero(BigDecimal)：替代 compareTo(BigDecimal.ZERO)，提升可读性
• 在领域模型中加入业务校验：如资产原值 > 0、累计折旧 ≥ 0 且 ≤ 原值、净值 = 原值 − 折旧，用 Objects.requireNonNull() 和自定义断言保障不变量。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
