Java中安全解析数字应采用“正则初筛+BigDecimal解析+Exact方法校验”策略，避免静默截断、溢出失真及异常混淆，推荐返回Optional并按业务定制规则。
Java 中用正则判断字符串是否为合法数字格式
直接用 Double.parseDouble() 或 Integer.parseInt() 做转换前，必须先过滤掉明显非法输入（如 "123abc"、" - 45"、"1e5.2"），否则会抛 NumberFormatException。正则不能只写 "\d+"——它连负号、小数点、科学计数法都拦不住。
推荐按需选择以下模式：
- 整数（含负号）：
^-?\d+$（注意：不接受"+123"，如需支持加号，改用^[+-]?\d+$） - 带一位可选小数点的十进制数：
^-?\d+(\.\d+)?（但会误判"123."；更稳写法是^-?\d+\.\d+$或配合BigDecimal构造器校验） - 宽松浮点数（兼容常见输入）：
^-?\d*\.?\d+(?:[eE][+-]?\d+)?$（能匹配"-1.23e-4"，但无法排除"."或"e5"这类边缘非法串）
真正可靠的做法不是靠正则穷举所有合法形式，而是「先粗筛再实转」：用正则快速拒绝明显错误（如含字母、多余符号），再交由 Double.valueOf() 尝试解析并捕获异常。
安全转换工具类的核心设计原则
不要封装成「返回 int 或 double」的静态方法——一旦转换失败就只能抛异常或返回魔数（如 -1），调用方极易忽略错误。应统一返回 Optional<Number> 或自定义结果类（如 ParseResult<Integer>）。
立即学习“Java免费学习笔记（深入）”；
关键约束点：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 空字符串、
null、仅空白字符（" "）必须被识别为无效，不能靠trim()后直转——" "调用trim()变成空串，再进parseInt仍报错 - 数值范围必须检查：
"999999999999999999999"对long来说溢出，但正则和Double.valueOf()都不会报错，得靠BigInteger或BigDecimal的compareTo()显式比对边界 - 避免重复解析：同一个字符串若需转多种类型（如先试
int，失败再试long），应先用BigDecimal解析一次，再用其intValueExact()、longValueExact()等方法尝试提取，防止因舍入或精度丢失导致逻辑错乱
一个轻量但覆盖常见场景的工具方法示例
以下方法用于安全转 Integer，兼顾可读性与健壮性：
public static Optional<Integer> safeToInt(String s) {
if (s == null || s.trim().isEmpty()) {
return Optional.empty();
}
String trimmed = s.trim();
// 快速排除明显非法字符（保留数字、-、+、.，但 . 不能单独存在）
if (!trimmed.matches("^[+-]?(\d+\.?|\d*\.\d+)([eE][+-]?\d+)?$")) {
return Optional.empty();
}
try {
BigDecimal bd = new BigDecimal(trimmed);
return Optional.of(bd.intValueExact());
} catch (NumberFormatException | ArithmeticException e) {
return Optional.empty();
}
}说明：
- 正则只做初筛，不追求 100% 数学正确性，重点挡掉
"12a3"、"1..2"这类明显错误 - 用
BigDecimal解析而非Double，避免"999999999999999999"被转成1e18后再取整失真 -
intValueExact()在溢出时抛ArithmeticException，比静默截断更安全
为什么不用 Apache Commons Lang 的 NumberUtils
NumberUtils.createInteger() 看似省事，但它有三个隐性风险：
- 对
"123.45"返回123（静默截断小数部分，业务上常属严重逻辑错误） - 对超范围值如
"2147483648"（int 最大值 +1）返回null，但文档未强调这是「溢出」还是「格式错误」，调用方难以区分原因 - 不支持自定义精度控制或上下文（如指定舍入模式），遇到金融类需求必须绕开
除非项目已重度依赖 Commons 且容忍其行为，否则手写轻量工具类反而更可控——尤其当需要明确区分「格式非法」「超出类型范围」「精度丢失」这三类错误时，通用工具库往往做不到。
最易被忽略的一点：不同业务对「数字」的定义可能完全不同。有的系统认为 "007" 是非法（要求无前导零），有的却要求保留。正则和转换逻辑必须按实际契约定制，没有银弹。
