从 “12.3” 的崩溃到完美的解决方案：一场类型选择的冒险之旅
从 “12.3” 的崩溃到完美的解决方案：一场类型选择的冒险之旅
“程序员的代码就像人生的旅途，总有那么几个坑等着你跳进去，然后爬出来时满身泥泞却笑得灿烂。”
—— 某不愿透露姓名的开发者
今天，我们要聊聊一个看似不起眼却能让人抓狂的问题：参数解析失败，以及它背后引发的类型选择大戏 。从 Java 的 Integer 到 MySQL 的 VARCHAR，再到 BigDecimal 的登场，这不仅是一次技术 debug 的过程，更是一场对需求、精度和未来的深刻反思。准备好了吗？让我们开始这场冒险吧！✨
问题的起源：一场 JSON 的“误会”
故事从一个日志开始，时间定格在 2025年3月10日，一个普通的周日（还是周一？程序员哪有周末 ）。日志里跳出一堆红色的错误：
ERROR 20625 --- [io-8087-exec-10] : 参数解析失败
HttpMessageNotReadableException: JSON parse error:
Cannot deserialize value of type `java.lang.Integer` from String "12.3":
not a valid Integer value
翻译成人话：Spring 试图把 JSON 中的 "12.3" 塞进一个 Integer 类型的 purchasePrice 字段，结果翻车了 。为什么？因为 Integer 只认整数（12、100），而 "12.3" 是个带小数点的家伙，Jackson（Spring 的 JSON 解析器）直接懵了：这啥玩意儿？我不会！
深挖根源
- 代码期待:
purchasePrice被定义为Integer，纯洁的整数世界。 - 现实打击: JSON 输入却是
"12.3"，一个浮点数，带着小数点的傲娇态度。 - 结果: 类型不匹配，程序崩溃，程序员加班 。
这让我不禁思考：类型选择真的只是代码里的一行定义吗？还是业务需求的镜子？
第一幕：从 Integer 到 Double 或 Float 的跃迁
既然 Integer 容不下 "12.3"，那就换个能装小数的类型吧！候选人有两个：Float 和 Double。但选谁呢？这可不是随便拍脑袋的事儿，咱得有点依据 ⚖️。
Float vs Double：一场精度与内存的较量
-
Float（单精度，32 位）- 优点：内存小，跑得快（理论上）。
- 缺点：精度只有 6-7 位，小数多了就“糊”了。
- 场景：适合小范围、低精度的浮点数，比如 12.34。
-
Double（双精度，64 位）- 优点：精度高达 15-16 位，小数随便玩儿。
- 缺点：内存翻倍，但现代硬件根本不在乎这点开销。
- 场景：需要高精度，比如 123.456789。
抉择时刻
purchasePrice 是“购买价格”，听起来像是货币相关的字段。现实中，价格通常带小数（12.99、123.45），而且谁知道未来会不会有更复杂的计算（税率、折扣）？所以，Double 看起来更靠谱 。代码改成这样：
public class FakeRegistration {
private Double purchasePrice; // 从 Integer 升级到 Double
// getter 和 setter
}
问题解决了吗？理论上是的！"12.3" 能被愉快地解析，程序员也能愉快地下班了 。但等等，事情没那么简单……
第二幕：货币的陷阱与 BigDecimal 的救赎
就在我以为万事大吉时，一个问题冒了出来：如果是货币，Double 真的安全吗？
浮点数的“原罪”
Float 和 Double 虽然能存小数，但它们是浮点数，用二进制近似表示十进制。这导致一个经典问题：精度误差。例如：
double a = 0.1;
double b = 0.2;
System.out.println(a + b); // 输出：0.30000000000000004
对普通计算，这点误差无所谓。但如果是货币，0.00000004 的误差可能让财务抓狂，甚至让老板扣你工资 。对于 purchasePrice 这种价格字段，精度可不是开玩笑的！
BigDecimal 登场
这时，BigDecimal 像个英雄一样走上舞台 。它不是浮点数，而是任意精度的十进制数，专为精确计算而生。看看它的表现：
BigDecimal a = new BigDecimal("0.1");
BigDecimal b = new BigDecimal("0.2");
System.out.println(a.add(b)); // 输出：0.3
完美！没有误差，财务满意，程序员安心 。于是，代码再次升级：
import java.math.BigDecimal;
public class FakeRegistration {
private BigDecimal purchasePrice; // 终极形态
// getter 和 setter
}
反思
从 Integer 到 Double，再到 BigDecimal，这不是简单的类型替换，而是一次对业务本质的追问：我们到底需要什么？是速度？内存？还是精度？ 在货币场景下，精度显然是王道 。
第三幕：数据库的转型，从 VARCHAR 到 DECIMAL ️
前端和后端都搞定了，但还有个问题：MySQL 数据库里的 purchase_price 是 VARCHAR(255)！这意味着它现在存的是字符串（“12.3”），而我们要用 BigDecimal。怎么办？改表结构呗！
为什么不用 FLOAT 或 DOUBLE？
FLOAT和DOUBLE在 MySQL 中也是浮点类型，照样有精度误差。- 我们需要的是定点数，也就是
DECIMAL（或NUMERIC），它能精确存储十进制数，和BigDecimal天生一对 。
修改表结构
原来的表定义是这样的：
CREATE TABLE `fake_registration` (
...
`purchase_price` varchar(255) DEFAULT NULL,
...
);
改成：
CREATE TABLE `fake_registration` (
...
`purchase_price` DECIMAL(10, 2) DEFAULT NULL, -- 总共10位，小数2位
...
);
DECIMAL(10, 2): 整数部分 8 位（99999999），小数部分 2 位（.99），范围够用，精度够高。- 如果已有表，用这个命令改：
ALTER TABLE `fake_registration`
MODIFY COLUMN `purchase_price` DECIMAL(10, 2) DEFAULT NULL;
数据迁移
如果表里已经有 “12.3” 这样的字符串，MySQL 会自动尝试转换。但要小心，确保数据干净，不然可能会报错 ⚠️。建议备份后再操作，别到时候哭着找 DBA 。
尾声：类型选择的哲学
从 "12.3" 的解析错误，到 BigDecimal 和 DECIMAL 的完美组合，这场冒险让我感慨万千：
-
需求的影子
类型不是代码的装饰品，而是业务需求的投影。purchasePrice从整数到浮点，再到高精度十进制，反映了我们对价格本质的重新认识。 -
精度与性能的平衡
Float省内存，Double高精度，BigDecimal保平安。每种类型都有它的舞台，关键是选对角色 。 -
未来的伏笔
今天选DECIMAL(10, 2)够用了，但如果业务扩展到国际贸易，价格变成 12345678.1234 怎么办？类型选择不仅是解决现在，更是留给未来的余地。
意味深长的结语
程序员的日常不仅是修 bug，更是与需求、系统和未来对话的过程。一次类型错误，可能只是冰山一角；一次深思熟虑的选择，却能让代码如诗般优雅，让系统如磐石般稳固。下次遇到类型问题时，你会怎么选呢？
✨ 感谢阅读！如果这篇文章让你有所收获，别忘了点赞、收藏，或者扔个表情告诉我你的想法！
有问题？评论区见，咱们一起解锁更多技术秘密！
