Postgres移除正则锚点后为何未按贪婪规则匹配？

核心原因是PostgreSQL与Java采用的正则引擎规范不同，导致无锚点场景下的非贪婪匹配行为逻辑存在明显区别：

1. 引擎底层规范差异 #

• Java使用Perl兼容正则表达式（PCRE），匹配逻辑倾向于寻找「最靠左的最长有效匹配」；
• PostgreSQL使用POSIX扩展正则表达式（ERE），匹配逻辑倾向于寻找「最靠左的最短有效匹配」。

2. 带锚点场景的一致表现 #

当正则带^$锚点时（^(.*?)([0-9]+)(.*)$），两种引擎都会被强制要求匹配整个字符串：

• (.*?)只能匹配到第一个数字前的所有非数字字符（abc）；
• ([0-9]+)必须匹配全部连续数字（12345）；
• (.*)匹配剩余的def；
  因此最终拆分结果完全一致。

3. 无锚点场景的行为差异 #

Java replaceFirst的处理逻辑 #

Java的PCRE引擎在执行replaceFirst时，会从字符串起始位置开始，优先选择能覆盖最多内容的匹配方案：

• 虽然(.*?)是非贪婪匹配，但引擎会判断：如果让(.*?)匹配abc，后续的([0-9]+)可以匹配全部连续数字，(.*)匹配剩余字符，这样整个字符串都能被匹配，这是最合理的最长有效匹配，因此会直接替换整个字符串，得到正确的三部分拆分结果。

PostgreSQL regexp_replace的处理逻辑 #

PostgreSQL的POSIX ERE引擎严格遵循「非贪婪匹配优先满足最短匹配」的规则，且无锚点时不需要匹配整个字符串：

• (.*?)匹配到abc后，后续的([0-9]+)只要匹配至少一个数字（即1）就满足正则要求；
• 此时(.*)会匹配下一个字符2，形成abc12这个最短的有效匹配子串；
• 最终regexp_replace仅替换这个子串，剩余的345def会保留下来，就出现了你看到的「数字组仅匹配单个数字，剩余字符未被替换」的结果。

总结 #

两者的差异本质是正则引擎对「匹配优先级」的定义不同：Java优先保证匹配的覆盖范围，而PostgreSQL优先保证匹配的早出现和短长度。如果要让PostgreSQL在无锚点时也能正确匹配整个字符串，保留^$锚点是最直接的解决方案。

内容的提问来源于stack exchange，提问作者Tomáš Záluský