Matcher.find() 是提取数字的核心动作，需循环调用才能逐个获取所有匹配项，单次调用仅得首个数字；配合 group() 获取字符串后，须校验并安全转为数值类型，且 Pattern 应复用以提升性能。
Matcher.find() 是提取数字的核心动作
Pattern 编译正则，Matcher 执行匹配，但真正「捞出数字」靠的是 find() 循环调用 —— 它不是一次性返回所有结果，而是逐个定位匹配片段。不循环调用 find()，就只能拿到第一个匹配或根本拿不到。
常见错误是写完 matcher.find() 就直接 matcher.group()，结果只取到首个数字；或者误用 matches()（全串匹配），导致永远返回 false。
- 用
\d+匹配连续数字（如 "abc123def45" → "123", "45"） - 若要支持负数和小数，改用
-?\d+\.?\d*，但注意它会把 "123." 也当作匹配，需根据场景微调 - 每次
find()成功后，立刻用group()获取当前匹配字符串，再转成int或double
Pattern.compile() 的 flag 影响数字提取的边界行为
默认情况下，\d+ 不会跨单词匹配，但如果你的源字符串含 Unicode 数字（如中文数字“一”或阿拉伯-印度数字“١٢٣”），普通 \d 无法识别 —— 这时需要 Pattern.UNICODE_CHARACTER_CLASS 标志。
另一个易忽略点：Pattern.CASE_INSENSITIVE 对数字无效，但若正则里混了字母（如提取 "version2.3.1" 中的版本号数字），加它没坏处；而 Pattern.DOTALL 和数字提取基本无关，加了反而干扰判断。
- 纯 ASCII 数字：不用额外 flag，
Pattern.compile("\d+")足够 - 含 Unicode 数字字符：用
Pattern.compile("\d+", Pattern.UNICODE_CHARACTER_CLASS) - 想忽略前后空白干扰（如 " 42 "），可在正则前后加
\s*，而不是依赖 flag
提取结果为 String 还是数值？类型转换要防异常
matcher.group() 返回的是 String，不是数字。直接 parse 可能抛 NumberFormatException，尤其当正则不够严谨时（比如匹配到空字符串、只有小数点、超长整数）。
典型翻车场景：用 -?\d*\.\d* 匹配小数，结果 "." 或 "123." 也被捕获，Double.parseDouble() 直接崩溃。
- 先用
!group.isEmpty()排除空匹配 - 整数转换前，用
group.matches("-?\d+")二次确认格式（比 try-catch 更轻量） - 小数建议用
BigDecimal解析，避免浮点精度丢失和异常范围问题 - 如果只要首个数字，用
find()+break即可，别硬写 while 循环
性能提示：Pattern 复用比反复 compile 快得多
同一个正则多次使用时，Pattern.compile() 是开销大户。每次 new Matcher 都该复用已编译的 Pattern 实例，而不是在循环里重复 compile。
更隐蔽的问题是：有人把 Pattern 声明为局部变量又在频繁调用的方法里反复创建，GC 压力明显上升，尤其在日志解析等高频场景。
- 将常用 pattern 提取为
private static final Pattern DIGIT_PATTERN = Pattern.compile("\d+"); - 每次提取时调用
DIGIT_PATTERN.matcher(input)，不要Pattern.compile("\d+").matcher(input) - 如果正则随输入动态变化（如用户自定义规则），才考虑缓存
ConcurrentHashMap，但注意 key 要归一化（trim、去空格）
正则提取数字看着简单，真正上线后出问题的，八成卡在边界匹配没控住、类型转换没兜底、或者 pattern 没复用。这三块不盯紧，日志里突然冒出 NumberFormatException 或漏掉某个带符号的温度值，都很难快速回溯。
