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 处理请求时才触发，说明该正则未被预编译（常见于错误使用变量导致无法静态分析）。
