Java字符串转数字时，parseInt和parseDouble遇非法格式直接抛NumberFormatException而非返回null或默认值，必须try-catch处理；空/空白字符串需trim后校验；valueOf与parseInt行为一致，仅返回类型不同。
Java字符串转数字时，parseInt 和 parseDouble 会直接抛异常，不返回 null 或默认值
这是最常被误用的一点：这些静态解析方法在遇到非法格式（如空字符串、含字母、纯空白、超出范围）时，一律抛出 NumberFormatException，而不是返回 null 或 0。这意味着你不能靠返回值判空来规避错误，必须显式捕获异常。
- 空字符串
""、仅空白字符（如" "）都会触发异常 -
parseInt("123abc")在第一个非法字符处失败，不尝试截断或忽略 -
parseDouble("NaN")或"Infinity"虽然语义上是数字，但默认不接受——除非字符串恰好是"NaN"或"Infinity"（注意大小写），否则仍报错 - 数值超出目标类型范围（如
parseInt("3000000000")）也会抛出异常，不是静默截断
想安全转换？别裸调 parseInt，先 trim + try-catch 是底线
没有“内置安全版”，但可以封装一层最小防御逻辑。重点不是避免异常，而是让异常发生得明确、可控。
- 必须调用
str.trim()，否则" 42 "会被parseInt拒绝（JDK 7+ 其实支持前后空格，但旧版本和部分 Android Runtime 不稳定，统一 trim 更可靠） - 空或全空白字符串应提前拦截，避免进到 parse 流程再抛异常
- 不要在 catch 块里吞掉异常并返回魔数（如 -1 或 0），这会让调用方无法区分“真值为 0”和“转换失败”
- 示例安全封装：
public static Integer parseIntSafe(String s) {
if (s == null || s.trim().isEmpty()) return null;
try {
return Integer.parseInt(s.trim());
} catch (NumberFormatException e) {
return null; // 或抛自定义业务异常
}
}
Integer.valueOf() 和 parseInt() 行为一致，但返回类型不同
很多人以为 valueOf 更“安全”或更“智能”，其实它底层就是调用 parseInt，只是多包了一层 Integer 对象。两者的输入校验逻辑完全相同，异常类型、触发条件一模一样。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
Integer.valueOf("123")→ 返回缓存的Integer实例（-128 到 127）；parseInt("123")→ 返回基本类型int -
Integer.valueOf("abc")和parseInt("abc")都抛NumberFormatException - 如果需要对象类型且可能为 null，用
valueOf封装更自然；如果后续要算术运算，用parseInt避免自动拆箱开销
批量解析或高并发场景下，异常成本高，考虑预校验或第三方库
频繁触发 NumberFormatException 会影响性能——异常构造栈信息开销大，尤其在日志全开或监控埋点密集时。这不是理论问题，在解析日志字段、API 参数批量导入等场景真实存在。
立即学习“Java免费学习笔记（深入）”；
- 正则预筛（如
str.matches("-?\d+")）适合整数，但要注意负号、前导零、溢出仍需 parse 验证 - Apache Commons Lang 的
NumberUtils.toInt(str, defaultValue)提供默认值机制，内部仍是 try-catch，但封装干净；注意它对空/空白返回默认值，不抛异常 - Gson/Jackson 解析 JSON 时若字段声明为
int但值为字符串，会直接失败——此时应在反序列化前用@JsonDeserialize自定义处理，而非依赖 parse 方法兜底
真正难处理的从来不是“怎么写对”，而是“怎么让错误路径不掩盖业务意图”。比如前端传了 "null" 字符串，后端该当空值还是非法输入？这个边界必须由业务规则定义，而不是交给 parseInt 的异常去回答。
