ngx_regex_t是Nginx对PCRE编译后pcre_t*的封装，不实现算法而调用PCRE；预编译发生在配置解析阶段和worker进程初始化阶段，由ngx_regex_compile()完成，并通过cycle级缓存复用。

ngx_regex_t 是什么，和 PCRE 有什么关系

ngx_regex_t 是 Nginx 内部封装的正则表达式句柄类型，本质是对 PCRE（Perl Compatible Regular Expressions）编译后 pcre_t* 结构的包装。它不自己实现匹配算法，而是调用 PCRE 库完成编译、执行和释放。Nginx 在启动或重载时，会将配置中所有正则表达式（如 location ~ .php$、if ($args ~ foo)）预编译为 ngx_regex_t 实例，并缓存到全局正则池中，避免运行时反复编译开销。

预编译发生在哪几个阶段

Nginx 的正则预编译主要在两个关键节点触发：

• 配置解析阶段（ngx_conf_parse）：当配置指令（如 location、rewrite、map）携带正则参数时，Nginx 调用 ngx_regex_compile() 尝试立即编译。若失败（例如语法错误），直接报错退出；若成功，则生成 ngx_regex_t* 并挂到对应配置结构体字段（如 ngx_http_location_t.regex）上。
• worker 进程初始化阶段（ngx_worker_process_init）：部分正则（尤其是 map 模块中动态生成的、或带变量插值的）可能延迟到 worker 启动时才编译。此时调用 ngx_pcre_malloc_init() 初始化 PCRE 内存池，并批量编译未完成的正则，结果存入 ngx_cycle->regex_pool。

预编译的核心函数：ngx_regex_compile

ngx_regex_compile() 是整个流程的中枢，它封装了 PCRE 的 pcre_compile() 和 pcre_fullinfo()。关键行为包括：

• 将 Nginx 配置字符串（如 ".(php|html)$"）转为 C 字符串，传给 PCRE 编译；
• 自动添加 PCRE_DUPNAMES（支持命名捕获组重复）、PCRE_UTF8（若启用了 utf8 支持）等标志；
• 调用 pcre_fullinfo() 获取捕获组数量（captures）、名称表（name_table）等元信息，填入 ngx_regex_t 的 captures 和 name_data 字段；
• 把编译后的 pcre_t*、额外内存块（如 name_table）、以及自定义的 ngx_pool_t* 关联起来，确保生命周期一致。

缓存与复用：为什么同一个正则不会重复编译

Nginx 使用两级缓存机制防止冗余编译：

• 进程内缓存（cycle->regex_pool）：每个 cycle（即每次 reload）维护一个独立的正则池。相同 pattern + flags 的正则，在同一 cycle 中只会编译一次；后续遇到直接复用已有的 ngx_regex_t*。
• 共享内存缓存（仅限某些模块）：如 ngx_http_map_module 在使用 hostnames 或 regex 时，会尝试从 shm 中查找已编译正则（需开启 map_hash_max_size 等配合），但默认仍走 cycle 级缓存。
• 注意：不同 worker 进程各自拥有独立的 regex_pool，不存在跨进程共享正则对象；但因配置一致，各 worker 编译出的正则内容相同。

调试与验证预编译是否生效

可通过以下方式确认正则是否真正被预编译而非运行时编译：

• 启动时加 -t 参数测试配置：nginx -t 会完整走一遍 ngx_regex_compile()，失败则报错，成功说明预编译通过；
• 启用 debug 日志（error_log /path/debug.log debug;），搜索 "regex" 或 "pcre"，可看到类似 "compiled regex "\.php$"" 的日志；
• 在 ngx_regex_compile() 函数入口加 trace（如用 gdb 或 eBPF），观察是否在 master 进程解析配置时就被调用 —— 若只在 worker 处理请求时才触发，说明该正则未被预编译（常见于错误使用变量导致无法静态分析）。