NumberFormatException 是输入校验缺失的信号，应前置校验而非依赖 try-catch；推荐使用 Apache Commons Lang 的 NumberUtils 提供默认值、判断可创建性及自动 trim 的安全转换方法。
NumberFormatException 出现时，别急着 try-catch
它不是异常“发生了”，而是你本该提前挡住的信号。Java 的 Integer.parseInt()、Double.parseDouble() 这类方法只做转换，不负责校验——空字符串、纯空白、带单位的数字（如 "123px"）、科学计数法超限（如 "1e500"），全都会直接抛 NumberFormatException。
常见错误现象：Integer.parseInt(" ") 报错；Long.parseLong("99999999999999999999") 溢出报错；前端传来的 "null" 字符串被当字面量解析。
- 真正需要的是「能转才转」，而不是「转失败再兜底」
- 如果业务逻辑允许默认值（如 0 或 null），校验必须在 parse 前完成
- 注意
Integer.valueOf()和parseInt()行为一致，同样抛异常，别误以为包装类更“安全”
用 Apache Commons Lang 的 NumberUtils 更省心
自己写正则或 trim + isEmpty 判断，容易漏边界（比如 "
"、"＋123"、"0x1F"）。NumberUtils 提供了语义清晰的工具方法，底层已覆盖多数非数字输入场景。
使用场景：后端接收 HTTP 参数、配置文件读取、CSV 解析等不确定输入源。
立即学习“Java免费学习笔记（深入）”；
-
NumberUtils.toInt("123", -1)—— 转不了就用默认值，不抛异常 -
NumberUtils.isCreatable("12.5")—— 返回 boolean，适合做前置判断（支持小数、负数、带符号） -
NumberUtils.createInteger(" 456 ")—— 自动 trim，且返回Integer（可为 null），比parseInt多一层容错
注意：它不校验业务逻辑含义（比如“年龄不能为负”），只是语法合法性检查。
自定义校验时，正则要慎用
有人喜欢写 str.matches("-?\d+") 判断整数，但这个正则会放过 "-0"（合法）、拒绝 "+123"（其实 parseInt 支持），还无法处理千分位（如 "1,234"）或 Unicode 数字字符。
性能与兼容性影响：正则编译开销小，但维护成本高；对超长数字字符串（如 1000 位）做正则匹配可能意外变慢。
- 若必须用正则，优先用
NumberUtils.isCreatable()替代，它内部用的是 DFA，比正则更稳 - 需要支持小数？别手写
-?\d+\.?\d*，它会匹配 ".5" 和 "1."，而parseDouble()不认这两个 - 国际化场景下，
Character.isDigit()比\d更可靠（后者只匹配 ASCII 数字）
Spring Boot 接口参数校验怎么接住它
Controller 层收到字符串参数后，直接塞给 @RequestParam Integer id？不行。Spring 默认用 StringToNumberConverterFactory，失败时抛 MethodArgumentTypeMismatchException，但错误信息是英文、没上下文，前端难定位。
正确做法是把校验下沉到 DTO，并显式控制行为：
- 字段声明为
String id，然后在@Valid校验器里调用NumberUtils.isCreatable(id) - 或用自定义注解（如
@Numeric(min=1, max=999999)），在ConstraintValidator里调用NumberUtils.createLong(value)并判空 - 避免在
@InitBinder里全局注册StringToIntegerConverter，否则所有 String→int 转换都走同一套逻辑，灵活性差
容易被忽略的一点：HTTP 请求头里的数字型字段（如 X-Rate-Limit）也是字符串，别忘了它们。
