一、匹配模式：正则表达式的“开关”与“滤镜”

正则表达式本身是一套匹配规则，但光有规则还不够。你想想看，同样的一个模式，在不同场景下，行为可能完全不同。比如，^abc 在单行文本里匹配行首，到了多行文本里，它匹配的是每一行的开头。这就是匹配模式在起作用。

我个人习惯把匹配模式理解为“开关”或“滤镜”。它们不改变正则的语法结构，但会改变引擎解释和执行匹配的方式。在 POSIX 标准里，regcomp() 函数的第三个参数就是用来传递这些模式标志的。今天，我们就来拆解四个最常用的模式：基本匹配、忽略大小写、多行匹配、扩展正则。

1.1 基本匹配：默认行为，但别小看它

基本匹配，就是 regcomp() 的 flags 参数传 0 时的行为。说白了，就是“原样匹配”。

举个例子：

#include <regex.h>
#include <stdio.h>

int main() {
    regex_t regex;
    const char *pattern = "hello";
    const char *text = "Hello, world!";

    // 基本匹配，flags = 0
    int ret = regcomp(&regex, pattern, 0);
    if (ret) {
        printf("编译失败\n");
        return 1;
    }

    ret = regexec(&regex, text, 0, NULL, 0);
    if (ret == 0) {
        printf("匹配成功\n");
    } else {
        printf("匹配失败\n");
    }

    regfree(&regex);
    return 0;
}

这段代码输出什么？匹配失败。因为基本匹配是大小写敏感的，"hello" 和 "Hello" 不匹配。

嗯，这里要注意：基本匹配模式下，. 匹配除换行符外的任意字符，^ 和 $ 分别匹配整个字符串的开头和结尾。这些行为都是默认的，但很多人会忽略它们。

1.2 忽略大小写匹配（REG_ICASE）：让匹配更宽容

REG_ICASE 是我用得最多的模式之一。它的作用很简单：让正则引擎在匹配时忽略字母的大小写。

用法：

regcomp(&regex, pattern, REG_ICASE);

加上这个标志后，"hello" 就能匹配 "Hello"、"HELLO"、"hElLo" 等等。

我曾经在写一个配置文件解析器时，用户输入的字段名大小写不统一。有的写 "Timeout"，有的写 "timeout"，还有写 "TIMEOUT" 的。如果不用 REG_ICASE，我得写三个正则，或者用 [Tt][Ii][Mm][Ee][Oo][Uu][Tt] 这种又臭又长的模式。用了 REG_ICASE，一行代码搞定。

1.3 多行匹配（REG_NEWLINE）：让 ^ 和 $ 重新定义

这个模式有点意思。默认情况下，^ 匹配整个字符串的开头，$ 匹配整个字符串的结尾。但加上 REG_NEWLINE 后，它们的行为变了：

• ^ 匹配每一行的开头（即换行符之后的位置）
• $ 匹配每一行的结尾（即换行符之前的位置）

同时，. 不再匹配换行符 \n。

看个例子：

const char *pattern = "^hello";
const char *text = "world\nhello\nfoo";

// 不加 REG_NEWLINE：匹配失败，因为 ^ 只匹配整个字符串开头
// 加上 REG_NEWLINE：匹配成功，因为 ^ 匹配第二行的开头

为什么会这样？因为 REG_NEWLINE 改变了正则引擎对“行”的认知。默认情况下，整个字符串就是一行。加了 REG_NEWLINE，换行符就成了行的分隔符。

我记得有一次处理多行日志文件，每行开头是时间戳。我想提取所有以 "2024-" 开头的行。如果不加 REG_NEWLINE，^2024- 只能匹配第一行。加上 REG_NEWLINE 后，每一行都能被正确匹配。

1.4 扩展正则（REG_EXTENDED）：更强大的语法

POSIX 标准定义了两套正则语法：基本正则（BRE）和扩展正则（ERE）。默认情况下，regcomp() 使用 BRE。加上 REG_EXTENDED 后，就切换到 ERE。

两者的主要区别：

特性	基本正则（BRE）	扩展正则（ERE）
分组	需要转义：\(...\)	直接使用：(...)
重复次数	需要转义：\{m,n\}	直接使用：{m,n}
选择	不支持 |	支持 |
前向/后向引用	支持 \1 等	支持 \1 等

说白了，ERE 就是 BRE 的“去转义”版本。你不需要在 (、)、{、} 前面加反斜杠了。而且 ERE 多了 | 操作符，可以实现“或”匹配。

我个人习惯：只要不是必须兼容老旧系统，一律用 REG_EXTENDED。因为 ERE 的语法更直观，写起来更省心。

// BRE 写法：匹配 foo 或 bar
const char *bre_pattern = "foo\\|bar";  // 注意：需要转义 |

// ERE 写法：匹配 foo 或 bar
const char *ere_pattern = "foo|bar";
regcomp(&regex, ere_pattern, REG_EXTENDED);

你看，ERE 的写法是不是清爽多了？

1.5 组合使用：模式标志可以叠加

这些模式标志不是互斥的，你可以用 | 把它们组合起来：

// 同时启用忽略大小写和多行匹配
regcomp(&regex, pattern, REG_ICASE | REG_NEWLINE);

// 同时启用扩展正则和忽略大小写
regcomp(&regex, pattern, REG_EXTENDED | REG_ICASE);

// 三个全开
regcomp(&regex, pattern, REG_EXTENDED | REG_ICASE | REG_NEWLINE);

组合使用时，每个标志独立生效，互不干扰。比如 REG_EXTENDED | REG_ICASE，就是“用扩展正则语法，并且忽略大小写”。

1.6 知识体系：一张图看懂匹配模式

下面这张 SVG 图，帮你理清这四种模式的关系和适用场景：

1.7 实战建议：怎么选？

说了这么多，到底怎么选？我总结了几条经验：

• 写工具脚本、自己用：直接上 REG_EXTENDED | REG_ICASE，省心省力。
• 处理用户输入：如果用户可能输入大小写不统一的文本，加 REG_ICASE。
• 解析多行文件：比如日志、配置文件，加 REG_NEWLINE。
• 需要精确匹配：比如校验密码、验证码，用基本匹配（flags=0），别加 REG_ICASE。
• 兼容老旧系统：有些上古系统只支持 BRE，那就别用 REG_EXTENDED。

---