matcher.find() 未匹配到数字的主因是未调用find()就直接调用group()，或误用matches()（要求整串匹配）；正确流程是先find()返回true后再group()。
Matcher.find() 为什么没匹配到数字？
常见现象是写好了 Pattern.compile("\d+") 和 matcher.find()，但死活不进循环——根本原因是没调用 matcher.find() 就直接去取 matcher.group()，或者用了 matcher.matches()（它要求**整串匹配**，不是找子串）。
正确姿势是：先 find()，再 group()；每次 find() 移动到下一个匹配位置，不调用就永远停在开头。
- 必须在
find()返回true后才能调用group()，否则抛IllegalStateException -
matches()和lookingAt()不会推进匹配位置，不能替代find() - 如果字符串里有负数或小数，
"\d+"会漏掉-和.，得用"-?\d+\.?\d*"并注意小数点可能匹配空字符串
提取所有数字（含负数、小数）的可靠正则写法
单纯 "\d+" 只能抓自然数，实际场景中数字常带符号或小数点。但别一上来就写超长正则——先明确你要什么：
- 要整数（含负号）：用
"-?\d+"，注意-必须紧挨数字，否则可能误抓孤立减号 - 要小数（含负）：用
"-?\d+\.\d+"（强制有小数位），或更宽松的"-?\d*\.?\d+"（但会把"."单独当匹配） - 推荐折中：用
"-?\d+(?:\.\d+)?"，确保小数点后至少一位，且整体是合法数值片段 - 注意：Java 正则里
.要转义，\.才表示字面量小数点
Matcher.find() 循环中怎么安全取值？
很多人在 while (matcher.find()) 里直接 Integer.parseInt(matcher.group())，结果遇到大数或非整数格式就崩。这不是正则问题，是类型转换没兜底。
立即学习“Java免费学习笔记（深入）”；
- 先用
matcher.group()拿到字符串，再判断是否需要转数字——不是所有匹配都要转int - 若需转整数，用
Long.parseLong()防溢出，或捕获NumberFormatException - 想跳过前导零干扰？
"0*(\d+)"加括号分组，然后用matcher.group(1)取无零部分 - 多次调用
find()后，start()/end()返回的是当前匹配在原字符串中的下标，可用于定位上下文
性能和边界情况：为什么有时 find() 变慢或卡住？
正则本身没问题，但输入字符串含大量重复字符（比如一长串 "11111111..."）时，"-?\d+" 本身不会回溯爆炸，可一旦加上 .* 或 .*? 前后修饰，就容易触发灾难性回溯。
- 避免在数字提取场景用
".*\d+.*"这类贪婪跨段模式——你只想要数字，别让正则去“猜上下文” - 如果源字符串超长（如几MB日志），建议先用
String.indexOf()快速跳过明显不含数字的段，再对疑似区域用正则 - 编译
Pattern是重操作，提取逻辑复用时务必把Pattern.compile(...)提到方法外，做成static final - 注意
\d在 Unicode 模式下可能匹配全角数字（如０１２），如需严格 ASCII 数字，改用[0-9]
真正麻烦的从来不是写对正则，而是搞清你要的“数字”在业务里到底指什么：是文本里的数值字面量？还是带单位的度量（如 "12px"）？还是 ID 编号（允许前导零）？这些语义差异，光靠 find() 解决不了。
