NumberFormatException在字符串格式非法时抛出，如空串、纯字母、多余空格、Unicode零宽字符或超范围数值；应通过trim()校验、null检查及try-catch或Optional封装安全转换。

NumberFormatException是什么时候抛出的

当用 Integer.parseInt()、Long.parseLong()、Double.parseDouble() 这类静态解析方法尝试把一个非法格式的字符串转成数字时，JVM 就会直接抛出 NumberFormatException。它不是运行时偶然出错，而是输入本身就不满足数字语法——比如空字符串、纯字母、带多余空格、含 Unicode 零宽字符、或超出目标类型的取值范围（如 "2147483648" 转 int）。

怎么安全地做字符串转数字

别让程序在解析失败时崩溃，得提前兜底。核心思路是：先校验再转换，或者用 try-catch 捕获并提供默认值或错误提示。

• 对简单场景（如表单输入），用 try-catch 最直接：

  String input = "123abc";
  int value;
  try {
      value = Integer.parseInt(input);
  } catch (NumberFormatException e) {
      value = 0; // 或抛自定义异常、记录日志、返回 Optional.empty()
  }

• 若需复用校验逻辑，可封装工具方法，避免重复写 try-catch：

  public static Optional<Integer> parseIntSafe(String s) {
      if (s == null || s.trim().isEmpty()) return Optional.empty();
      try {
          return Optional.of(Integer.parseInt(s.trim()));
      } catch (NumberFormatException e) {
          return Optional.empty();
      }
  }

• Java 17+ 可考虑 Integer.decode()，它支持十六进制前缀（如 "0xFF"），但依然会抛 NumberFormatException，不能替代校验。

常见踩坑点：trim() 和 null 检查容易被忽略

很多 NumberFormatException 其实源于肉眼难辨的空白字符，比如首尾空格、全角空格、或不可见控制符（如 u200B）。不调用 trim() 就直接解析，" 42 " 会失败；传入 null 则必然触发异常——parseInt(null) 不会返回 0，而是立刻抛错。

Apache Tika Content Extraction Hub

通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。

下载

• 永远在 parse 前检查 s == null 或 s.isEmpty()
• trim() 是低成本高收益操作，建议无条件加上
• 不要依赖前端/上游“保证输入干净”——网络请求、文件读取、数据库字段都可能混入脏数据

性能与替代方案：什么时候不该用 parseInt

如果高频解析且输入基本可信（如内部配置、枚举序号），parseInt 没问题；但若大量不确定输入（如用户评论里的数字提取），频繁抛异常会影响性能——异常创建栈信息开销大。

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

• 正则预筛：用 s.matches("-?\d+") 快速过滤纯整数字符串（注意不支持科学计数法和小数）
• Apache Commons Lang 的 NumberUtils.toInt(s, defaultValue) 内部已处理 null/空/异常，适合快速替换
• 需要解析带单位的字符串（如 "1.5GB"）或容忍模糊格式，就该用专门的解析器，而不是硬塞给 parseDouble

实际项目里，最常被漏掉的是对空字符串和全角空格的处理。哪怕加一行 s = s == null ? "" : s.trim()，都能避开一大半线上报错。