Kotlin中浮点数计算的精度陷阱与BigDecimal的救赎之路

正文：

在Kotlin的世界里，浮点数计算就像一把刻度模糊的尺子——看似精准，实则暗藏玄机。当你信心满满地敲下0.1 + 0.2 == 0.3的表达式时，编译器返回的false如同当头棒喝。这不是代码的背叛，而是计算机科学中经典的精度陷阱在作祟。

一、浮点数的精度之谜
Kotlin的Double和Float类型遵循IEEE 754标准，采用二进制存储。但人类世界的十进制小数（如0.1）在二进制中是无限循环小数。就像1/3在十进制中写作0.333…一样，这种转换必然导致精度丢失。

尝试运行以下代码：

fun main() {
    val a = 0.1 + 0.2
    println(a == 0.3)         // 输出：false
    println("%.20f".format(a)) // 输出：0.30000000000000004441
}

这个微小的误差在金融计算中可能引发雪崩式灾难。想象一下：电商平台因0.00000000000000004的误差导致百万级订单金额偏差，后果不堪设想。

二、BigDecimal的精确之道
java.math.BigDecimal通过分离整数和小数部分，采用BigInteger存储数值，配合独立的缩放因子（scale）记录小数位数。这种设计让它成为金融计算的黄金标准。

正确使用姿势：

import java.math.BigDecimal
import java.math.RoundingMode

fun main() {
    // 务必使用字符串构造！避免二次精度丢失
    val a = BigDecimal("0.1")
    val b = BigDecimal("0.2")
    val c = BigDecimal("0.3")

    println(a + b == c) // 输出：true

    // 精确货币计算示例
    val price = BigDecimal("99.99")
    val quantity = BigDecimal("3")
    val discount = BigDecimal("0.8") // 八折

    val total = price * quantity * discount
        .setScale(2, RoundingMode.HALF_UP) // 保留两位小数，银行家舍入

    println(total) // 输出：239.98
}

三、实战避坑指南
1. 构造陷阱：永远用字符串初始化BigDecimal。BigDecimal(0.1)会先将0.1转为不精确的double，造成不可逆精度损失
2. 小数位控制：用setScale()显式指定精度和舍入模式。金融计算常用RoundingMode.HALF_UP（四舍五入）
3. 等值比较：优先使用compareTo() == 0而非equals()。后者会严格比较精度，BigDecimal("1.0")和BigDecimal("1.00")不等
4. 性能权衡：大数据量计算时，BigDecimal比原生浮点慢10-100倍。对精度不敏感的场景可考虑Double配合误差容忍范围

四、现代Kotlin的优雅实践
结合扩展函数，让精确计算更符合Kotlin风格：

// 定义扩展属性
val Int.bd get() = BigDecimal(this.toString())
val String.bd get() = BigDecimal(this)

// 扩展函数处理常见计算
fun BigDecimal.percent(percent: Int): BigDecimal {
    return this * (percent.toBigDecimal() / 100.bd)
}

fun main() {
    val salary = "5000".bd
    val tax = salary.percent(15).setScale(2, RoundingMode.DOWN)
    println("需纳税：$$tax") // 输出：需纳税：$750.00
}

当你在Kotlin中处理金钱时，请时刻谨记：浮点数是近似值，BigDecimal才是真相。精度问题不会因语言的高级特性而消失，唯有理解计算机的底层逻辑，才能在数字世界中避免失之毫厘谬以千里的悲剧。