优先用Integer.valueOf()（返回缓存Integer对象）而非parseInt（返回基本int）；parseDouble有宽松解析隐患；BigDecimal必须用字符串构造避免精度丢失。
Java字符串转int：用Integer.parseInt()还是Integer.valueOf()？
两者都能完成转换，但行为有关键区别：Integer.parseInt("123")返回基本类型int，而Integer.valueOf("123")返回Integer对象（内部会缓存-128~127的实例）。如果后续要调用对象方法（如compareTo）或放进集合，优先用valueOf；若只是做计算且确定不为null，parseInt更轻量。
常见错误：Integer.parseInt("12.5")抛NumberFormatException；Integer.parseInt(" 123")也失败（开头空格不被跳过）。需提前用trim()或正则校验。
- 空字符串、null、含非数字字符（包括全角数字、逗号、+/-位置错）都会触发异常
- 值超出
int范围（如"2147483648"）同样抛NumberFormatException - 若想安全转换，建议封装一层：先
str == null || str.trim().isEmpty()判空，再try-catch
字符串转double：注意精度丢失和解析宽松性
Double.parseDouble("1.23")能接受科学计数法（如"1.23e2"）、前导空格、甚至"Infinity"或"NaN"字面量——这既是便利也是隐患。比如Double.parseDouble("123.4567890123456789")实际只保留约15位有效数字，后续做金额比对会出错。
典型陷阱：
立即学习“Java免费学习笔记（深入）”；
-
Double.parseDouble("123,456.78")失败（英文逗号不被识别为千分位） -
Double.parseDouble("123.45.67")只取首段，结果是123.45（不报错！） -
Double.parseDouble("")或null直接抛NumberFormatException
若业务要求严格格式（如金额、坐标），别依赖parseDouble自动容错，应先用正则限定格式，或改用BigDecimal构造器。
字符串转BigDecimal：为什么不能用new BigDecimal(double)？
这是最常被踩的坑。new BigDecimal(0.1)结果是0.1000000000000000055511151231257827021181583404541015625——因为double本身是二进制浮点数，无法精确表示十进制小数。正确做法永远是用字符串构造：new BigDecimal("0.1")。
其他注意事项：
-
BigDecimal构造器对空格敏感：new BigDecimal(" 123 " )会抛NumberFormatException（必须trim） - 支持指数符号（
"1.23E-4"），但不支持中文数字、货币符号、千分位逗号 - 若源字符串可能为
null，别直接传入，先做Objects.requireNonNull(str, "value must not be null")或提供默认值逻辑
统一处理方案：要不要封装一个工具类？
项目里频繁出现字符串转数字，又不想每个地方都写try-catch，可以封装静态方法，但要注意边界：
- 不要让工具方法静默返回0或0.0——掩盖了原始数据问题，下游更难排查
- 可提供带默认值的重载，如
toInt(String s, int defaultValue)，但默认值不应是魔法数字（避免用-1代表“失败”） - 对
BigDecimal，建议额外提供toBigDecimal(String s, MathContext mc)支持精度控制 - 若涉及国际化输入（如德语用逗号作小数点），
NumberFormat比直接解析更合适，但性能差、线程不安全，需注意实例复用
真正复杂的不是转换动作本身，而是你得清楚这个字符串从哪来、是否可信、精度要求多高、出错时该告警还是降级——这些决定了该选哪个API，而不是背熟函数名。
