负向回顾后发断言不符合预期：匹配“up to”后数值异常

你遇到的问题核心在于正则没有将多位数视为一个整体匹配，而是逐个数字尝试匹配，导致负向回顾后发断言的检查范围失效。

具体来说，你的正则表达式 (?i)(?<!up\s{1}to\s{1})([0-9]{1,})\s*(GB|MB|KB) 中：

• [0-9]{1,} 会匹配单个或多个数字，但正则引擎会逐个字符尝试匹配。
• 当处理 up to 12 gb 时：
  1. 首先尝试匹配数字 1：它的前面是 up to ，负向断言 (?<!up\s{1}to\s{1}) 生效，因此不匹配 1 gb。
  2. 接着尝试匹配数字 2：它的前面是数字 1，并不满足 up to 的前置条件，所以断言不生效，最终匹配出 2 gb。

而当输入是 up to 1 gb 时，唯一的数字 1 前面是 up to ，断言生效，所以没有输出，符合预期。

要解决这个问题，我们需要确保整个数字序列作为一个整体被检查，不能让单个数字绕过断言。可以通过以下两种方式实现：

方案1：使用单词边界锁定数字整体 #

通过添加单词边界 \b，强制正则将连续数字视为一个整体，确保断言检查的是数字序列的起始位置：

(?i)(?<!up\s+to\s+)\b\d+\s*(GB|MB|KB)\b

• \b 是单词边界，确保我们匹配的是独立的数字序列（不会匹配数字的一部分）。
• \s+ 替代 \s{1}，更灵活匹配一个或多个空格（避免严格限制单个空格的情况）。

方案2：使用可变长度负向回顾后发断言（部分语言支持） #

如果你的正则引擎支持可变长度回顾后发断言（比如 Python 3.7+、Java 等），可以直接断言数字前面没有 up to 前缀：

(?i)(?<!up\s*to\s*)\d+\s*(GB|MB|KB)

• \s* 匹配零个或多个空格，兼容 upto、up to 等不规范写法。

• 输入 up to 12 gb：两种方案都不会匹配任何内容（符合预期）。
• 输入 up to 1 gb：无输出（符合预期）。
• 输入 available 500 MB：会匹配 500 MB（符合提取需求）。

内容的提问来源于stack exchange，提问作者Bhagwati Malav