ngx_pool_t是Nginx模块内存管理核心，需严格匹配请求/连接生命周期，禁跨池释放、混用malloc与pool分配，善用对齐预分配，并启用调试检测内存泄漏。
在 Nginx 模块开发中，ngx_pool_t 是核心内存管理机制，它替代了频繁的 malloc/free，避免内存碎片和系统调用开销。正确使用内存池不是“能用就行”，而是关系到模块稳定性、内存泄漏和并发安全的关键环节。
内存池生命周期必须与请求/连接上下文严格对齐
Nginx 的典型生命周期是：连接建立 → 请求接收 → 请求处理 → 响应发送 → 连接关闭。每个阶段有对应的内存池：
-
连接池（
c->pool）：生命周期为整个 TCP 连接，适合存放连接级数据（如 SSL 上下文、长连接缓存）； -
请求池（
r->pool） -
临时池（如
ngx_create_pool(4096)）：仅用于短时计算（如 URI 解析、变量拼接），必须在函数返回前显式销毁（ngx_destroy_pool()）或重置（ngx_reset_pool()）。
常见错误：在 handler 中长期持有请求池分配的指针，却在请求结束后续使用——此时池已被销毁，指针悬空。
禁止跨池释放、禁止混用 malloc 与 pool 分配
ngx_palloc/ngx_pcalloc 分配的内存只能由其所属池统一管理，不能传给 free()；反之，malloc 分配的内存也不能交由 ngx_destroy_pool() 处理。
- 模块中若需长期存活对象（如共享字典、全局配置缓存），应使用
ngx_cycle->pool或独立创建的永久池（并确保只在 master 进程退出时销毁）； - 需要动态增长的结构（如大数组、链表节点），优先用
ngx_array_t或ngx_list_t——它们底层自动适配内存池，且支持扩容； - 调用第三方库（如 PCRE、OpenSSL）时，若需传入缓冲区，务必用
ngx_pnalloc（不初始化）分配，并确认库不会尝试free它。
小块内存分配要善用对齐与预分配策略
Nginx 内存池默认按 16 字节对齐，但某些场景需显式控制：
- 分配结构体时，用
ngx_pcalloc（清零 + 对齐），避免未初始化字段引发未定义行为； - 连续分配多个同类型小对象（如 key-value 对），可先用
ngx_palloc申请一块大内存，再手动切分，比逐次分配更高效； - 避免在循环中反复调用
ngx_palloc分配极小内存（如每次 8 字节），可改用ngx_array_t管理，减少池内碎片。
调试阶段必须启用内存池检查与泄漏检测
生产环境默认不校验内存池操作，但开发时应主动开启防护：
- 编译时加
--with-debug，运行时设置NGX_DEBUG_MALLOC=1环境变量，使ngx_palloc插入边界标记，检测越界写； - 在模块 init 或 handler 结尾调用
ngx_log_debug打印r->pool->current->d.last - r->pool->current->d.start，观察单请求内存增长是否异常； - 使用
valgrind --tool=memcheck运行 Nginx（需关闭所有子进程、禁用信号处理），重点检查自定义池创建/销毁逻辑是否成对出现。
不复杂但容易忽略。
