NumberFormatException容错核心是保障程序不崩溃、逻辑可预期、用户有反馈，而非仅靠try-catch兜底；需前置校验（非空、格式、范围）区分错误类型，catch后须日志、默认值或业务异常，避免掩盖问题。
NumberFormatException 容错的核心不是“避免抛异常”，而是让异常发生时程序不崩溃、逻辑可预期、用户有反馈。
为什么不能只靠 try-catch 撑全场
单纯包一层 try-catch 虽能防止崩溃，但容易掩盖问题本质：比如把 "null"、""、" 42 "、"12.5"、"123abc" 全部归为“解析失败”，后续却统一返回 0 或 -1，可能引发业务误判。关键要区分是数据污染、录入错误，还是格式设计本身就不支持（如整数字段误传了小数）。
三步前置校验比纯捕获更高效
-
非空与空白处理：先判断
str == null || str.trim().isEmpty()，空值直接拒绝或设默认值，不进 parse 流程 -
粗筛格式合规性：对整数场景用
str.matches("-?\d+")，对浮点用str.matches("-?\d+(\.\d+)?")；注意这步不替代 parse，仅快速过滤明显非法串 -
范围预估（可选）：若已知合理数值区间（如年龄 0–120），可先用
str.length()和首字符快速排除超长串，减少 parse 溢出风险
捕获后该做什么，不是“吞掉”就完事
catch 块里必须明确行为：
- 记录带上下文的日志，例如
log.warn("用户ID参数解析失败，原始值='{}', 来源=web-form", rawInput) - 返回有意义的默认值（如分页 size 解析失败返回 10）、抛出带提示的业务异常（如
throw new ParamInvalidException("页码必须为正整数")），或引导前端重填 - 避免在高频循环中无差别 try-catch：批量解析前先用
NumberUtils.isParsable(str)（Apache Commons）或自定义白名单过滤，再集中 parse
更稳的替代方案推荐
不总依赖原生 parse 方法：
- 用
NumberUtils.toInt(str, defaultValue)—— 自动 trim、判 null、失败返回默认值，零异常开销 - 对精度敏感或大数场景，改用
BigDecimal或BigInteger，它们 parse 失败仍抛 NFE，但不会因溢出静默失真 - 表单类场景，结合 JSR-303 注解（如
@Digits、@Min）在绑定层拦截，不让非法字符串进业务逻辑
