REGEXP_MATCHES返回text[]数组，即使单匹配也含一个元素；最简调用为REGEXP_MATCHES(subject,pattern)，默认全局但仅返首匹配捕获组，需'g'标志配合UNNEST或LATERAL获取全部匹配。
REGEXP_MATCHES 函数的基本用法和返回结构
REGEXP_MATCHES 不是简单返回匹配字符串，而是返回一个 text[]（文本数组）——哪怕只有一组捕获，结果也是单元素数组。这点和很多语言的 match() 行为不同，容易误以为“没匹配到”或“结果不对”。
最简调用形式：REGEXP_MATCHES(subject, pattern)。它默认开启全局匹配（g），但每次只返回**第一个匹配项的所有捕获组**；若要获取全部匹配，必须配合 WITH ORDINALITY 或嵌套查询。
- 不加标志时，默认行为等价于带
'g'，但仅返回首个匹配的捕获组数组 - 想忽略大小写？加标志
'i'：例如REGEXP_MATCHES('AbC', 'abc', 'i') - 多行模式（
^/$匹配每行首尾）需显式加'n'，PostgreSQL 不默认启用
提取多个捕获组：括号顺序决定数组下标
正则中每一对 () 对应结果数组的一个元素，按左括号出现顺序编号，从 1 开始。比如 (\d+)-(\w+) 匹配 "123-abc"，结果是 {'123','abc'}，取第一个捕获组得 (REGEXP_MATCHES(...))[1]。
注意：未参与匹配的捕获组（如分支中未走通的 (a)|(b)）会返回 NULL，不是空字符串。
- 要安全取值，建议用下标访问并处理
NULL：(REGEXP_MATCHES(text_col, '(\d+)-(\w+)', 'g'))[1] - 如果只要第一个捕获组且确定有匹配，可直接展开：
(REGEXP_MATCHES('foo123bar', '(\d+)'))[1]→'123' - 避免写成
REGEXP_MATCHES(...)::text—— 这会把整个数组转成字符串如"{123,abc}"，不是你想要的字段值
一次提取所有匹配（不止第一个）
默认 REGEXP_MATCHES 只返回首个匹配的捕获组数组。要拿到字符串里**所有匹配结果**，必须让函数“生成多行”，常用方法是配合 UNNEST 或 WITH ORDINALITY。
典型写法：
SELECT (m)[1] AS number FROM (SELECT REGEXP_MATCHES('a1b22c333', '\d+', 'g') AS m) t;
这会返回三行：'1'、'22'、'333'。
- 关键在
'g'标志 + 子查询包裹 + 数组下标取值 - 若原字段可能无匹配，
REGEXP_MATCHES返回空集（0 行），不会报错，但外层(m)[1]不会执行 - 想保留原表每行记录并补
NULL（而非丢弃无匹配行）？改用LEFT JOIN LATERAL方式更稳妥
常见错误：空匹配、贪婪 vs 懒惰、性能陷阱
PostgreSQL 的正则引擎是 POSIX 兼容的，不支持懒惰量词（*?、+?）。写 .*? 会被当作普通 .*（贪婪），可能导致意外吞掉太多内容。
另一个高频坑：空字符串匹配。比如 REGEXP_MATCHES('abc', '.*') 会返回 {'abc'}，但 REGEXP_MATCHES('abc', '.*?') 实际行为等同于 .*，且可能在边界处产生空匹配（尤其配合 g 时）。
- 避免用
.*做主体提取，优先用否定字符类，如'[^,]+'替代'.*?, ' - 长文本 + 复杂正则易引发回溯爆炸，测试时用
EXPLAIN ANALYZE看实际执行时间 -
REGEXP_MATCHES无法直接替代REPLACE或SUBSTRING做简单切片——该用SUBSTRING(text FROM pattern)的地方别硬上正则函数
真正麻烦的从来不是语法，而是正则本身在 PostgreSQL 里没有 JIT 编译、不支持 Unicode 属性（如 \p{L}），以及捕获组嵌套深度受限。这些限制不到报错那一刻，往往想不到是引擎能力边界的问题。
