应根据语义和场景选择：需对象（如集合、泛型）用Integer.valueOf()，需基本类型数值计算用parseInt()；金融计算必须用BigDecimal(String)；判等须注意NaN和跨类型比较陷阱。

Integer.valueOf() 和 Integer.parseInt() 到底该用哪个？

二者都用于字符串转整数，但语义和异常行为完全不同：Integer.valueOf() 返回 Integer 对象（会走缓存），Integer.parseInt() 返回基本类型 int。关键区别在于空值和异常处理：

• Integer.valueOf(null) 直接抛 NullPointerException
• Integer.parseInt(null) 抛 NumberFormatException
• Integer.valueOf("123") 可能复用缓存对象（-128 ~ 127 范围内），而 parseInt 总是返回新计算的 int
• 如果后续要调用 .equals() 或传入泛型集合，优先用 valueOf()；若明确只需要数值计算，parseInt() 更轻量

Double.parseDouble() 在科学计数法下容易忽略的精度陷阱

Double.parseDouble("1.2345678901234567e10") 看似无害，但 double 本身只有约 15~17 位有效数字，超出部分会被静默舍入。这不是 bug，而是 IEEE 754 的固有限制：

• 不要用 Double 做精确金融计算——哪怕输入是字符串形式的“100.00”，转成 double 后可能变成 99.99999999999999
• 需要精确小数时，必须用 BigDecimal(String) 构造器，绝不能用 new BigDecimal(double)
• Double.parseDouble("NaN")、"Infinity" 是合法的，会分别返回对应特殊值，但多数业务逻辑未做防御性判断

Apache Commons Lang 的 NumberUtils 为什么比原生更实用？

原生 API 缺少安全兜底，而 NumberUtils 提供了大量防崩操作：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• NumberUtils.toInt("abc", 0) —— 解析失败时返回默认值，不抛异常
• NumberUtils.createInteger(" 42 ") 自动 trim 并处理空白，原生 parseInt 会直接报错
• NumberUtils.isCreatable("12.34") 可预检字符串是否可转为任意数字类型（包括浮点），避免 try-catch 泛滥
• 注意：它对 null 输入默认返回 null（对象方法）或 0（primitive 方法），行为需查文档确认，不是完全“零配置安全”

Integer 和 Double 的 equals() 比较为什么经常出错？

这是最隐蔽的坑：自动拆箱 + 缓存机制混合导致非对称行为。

立即学习“Java免费学习笔记（深入）”；

Integer a = 100;
Integer b = 100;
System.out.println(a.equals(b)); // true —— 缓存内同一对象

Integer c = 200;
Integer d = 200;
System.out.println(c.equals(d)); // true —— equals 比较的是数值，不是引用

Double e = 1.0;
Double f = 1.0;
System.out.println(e.equals(f)); // true

Double g = Double.NaN;
Double h = Double.NaN;
System.out.println(g.equals(h)); // false —— NaN.equals(NaN) 定义为 false！

• Integer 在 -128 ~ 127 范围内用缓存，但 equals() 仍按数值比较，所以不会出错
• Double.equals() 对 NaN 特殊处理：永远返回 false，哪怕两个都是 NaN
• 跨类型比较如 new Integer(1).equals(new Double(1.0)) 永远是 false（类型不同，不尝试转换）
• 判等务必先明确语义：是数值相等？还是对象身份？还是允许误差的浮点近似？

实际项目里，最常被漏掉的是 NaN 的显式校验和 BigDecimal 的构造方式。这两个点一旦出问题，往往出现在生产环境的边缘 case 里，日志还不容易暴露。