NumberFormatException本质是字符串无法构成合法数值字面量的硬性解析失败，需前置校验空值、空白及进制参数，推荐用NumberUtils.isCreatable()安全判断后再解析，溢出仍抛异常。
NumberFormatException 本质是解析失败，不是格式错误
它抛出的直接原因是字符串无法被转成目标数值类型，比如 "123abc" 转 Integer.parseInt()，或空串 ""、全空白 "\t\n "、null 直接传入。这不是“格式不规范”的模糊问题，而是“根本不能构成合法字面量”的硬性失败。
常见错误现象：NumberFormatException: For input string: ""、NumberFormatException: null、NumberFormatException: 0x1F（十六进制未指定进制参数）。
- 务必先做非空和非空白校验：用
Objects.nonNull(s)+!s.trim().isEmpty() - 不要依赖 try-catch 做主流程控制——它开销大，且掩盖了本该前置拦截的问题
-
Integer.parseInt()默认只认十进制；若要支持"0xFF"或"101010"，必须显式传进制参数，如Integer.parseInt("0xFF", 16)
用 NumberUtils.isCreatable() 替代手写正则
Apache Commons Lang 的 NumberUtils.isCreatable() 是少数能安全覆盖多数边界场景的工具方法：它接受 "123"、"-45.67"、"+0.0"、"1.23e4"，同时拒绝 "123."、"123abc"、" "、null。比自己写正则更可靠，也比反复 try-catch 更轻量。
使用场景：表单提交、配置文件读取、CSV 解析等上游数据不可控的环节。
立即学习“Java免费学习笔记（深入）”；
- 引入依赖：
org.apache.commons:commons-lang3:3.12.0及以上 - 判断后再解析：
if (NumberUtils.isCreatable(str)) { return NumberUtils.createInteger(str); } - 注意：它不校验溢出（如
"99999999999999999999"对 int 仍会抛异常），超长数需用BigInteger或提前截断
Long.parseLong() 和 Integer.parseInt() 的溢出行为完全一致
两者对超出范围的字符串（如 "2147483648" 对 int，或 "9223372036854775808" 对 long）都抛 NumberFormatException，而非静默截断或返回最大值。这点常被误认为“会绕过异常”，实际不会。
性能影响：溢出检测本身成本很低，但反复触发异常会显著拖慢吞吐——尤其在日志解析、批量导入等场景。
- 若已知输入可能超范围，优先用
BigInteger解析再比较：new BigInteger(str).compareTo(BigInteger.valueOf(Integer.MAX_VALUE)) - 或用 Guava 的
Ints.tryParse()/Longs.tryParse()，返回null而非抛异常，适合高频校验 - 避免在循环内对同一字符串反复调用
parseInt——解析结果应缓存或一次完成转换
JSON 反序列化时的 silent fallback 风险
像 Jackson 默认把无法转数字的 JSON 字符串（如 "abc"）反序列化为 0 或 0L，而不是报错。这看似“友好”，实则掩盖了上游数据污染，后续计算出错才暴露，定位极难。
使用场景：微服务间 JSON 接口、前端传参、数据库 JSON 字段解析。
- Jackson 应禁用 silent fallback：配置
DeserializationFeature.FAIL_ON_NUMBERS_FOR_ENUMS = false不相关，真正要设的是DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES = true，并配合自定义JsonDeserializer拦截非法字符串 - Gson 默认更严格，但若用了
LenientDateFormat类似宽松模式，也可能跳过校验——确认GsonBuilder未调用lenient() - 最稳妥方式：在 DTO 字段上加
@JsonDeserialize(using = StrictNumberDeserializer.class)，内部用NumberUtils.isCreatable()兜底
真正麻烦的不是“怎么转”，而是“谁该负责校验”。上游接口不校验、中间件默默 fallback、下游又用原始字符串拼 SQL——这种链路里，NumberFormatException 往往是最后一个被发现的症状，而不是第一个该拦截的点。
