Nginx内存池是为请求/连接级短生命周期设计的轻量方案：小块≤4KB在线性区偏移分配，大块走独立large链表；按请求绑定生命周期，子请求须建独立子池；禁用libc分配，统一用pool-aware接口；复用buf/chain降低碎片。
Nginx 的内存池（Memory Pool）不是通用堆管理器，而是一套为“请求/连接级短生命周期”量身定制的轻量级内存方案。它不追求灵活释放，而是用确定性换稳定性——所有小块内存在线性区偏移分配，整池销毁；大块走独立链表；绝不跨请求复用 pool 指针。这是它扛住万级并发却不崩、不漏、不碎的根本逻辑。
按请求/连接粒度绑定生命周期
每个 HTTP 请求（ngx_http_request_t）或 TCP 连接都会调用 ngx_create_pool() 创建专属内存池，该池随请求结束自动触发 ngx_destroy_pool() 彻底释放。这种“归属即销毁”的模型彻底规避了传统 malloc/free 中因释放顺序错乱、异常跳转遗漏导致的内存泄漏与堆碎片。
- 请求处理中所有临时缓冲区、头字段解析结构体、重写变量等，都应从当前 request pool 分配
- 子请求（subrequest）必须创建独立子池，不可复用父请求 pool
- 定时器回调、异步 I/O 完成事件若需内存，应显式使用 cycle->pool 或新建子池，绝不能误用已即将销毁的 request pool
小块与大块内存的差异化分配策略
Nginx 默认以 4KB 为阈值区分两类内存：小块（≤4KB）在线性池中靠移动 last 指针分配，无元数据、无对齐开销；大块（如上传 body 缓存、SSL session 缓存）则通过 large 链表单独 malloc，避免撑爆主池或造成内部碎片。
- 小块分配推荐用 ngx_pcalloc()（自动清零），避免未初始化内存引发未定义行为
- 大块内存可调用 ngx_palloc_large()，也可由模块自行 malloc 后手动挂入 pool->large 链表，确保池销毁时一并清理
- 禁止在小块区强行分配超限内存——会导致分配失败或越界，应主动降级走 large 路径
统一使用 pool-aware 接口，杜绝隐式堆分配
所有模块必须严格使用 ngx_palloc / ngx_pcalloc / ngx_pnalloc 等接口，禁用 malloc / calloc / strdup 等 libc 函数。否则会破坏内存归属关系，使 pool 销毁后仍有指针指向已失效内存。
- Lua 模块中避免高频使用 string.format 和 table.concat，它们可能触发 Lua GC 或底层 libc 分配
- 第三方模块（如 headers-more、echo-nginx-module）需检查是否含隐式 malloc；优先选用提供 pool-aware 版本的接口（如 ngx.shared.DICT 替代 Lua table 缓存）
- 结构体内嵌字符串建议用 ngx_str_t + ngx_pnalloc 分离分配，而非直接声明固定长度数组
缓冲区与链表节点的复用降低碎片源头
HTTP 处理中 ngx_buf_t 和 ngx_chain_t 频繁创建销毁，是碎片高发区。Nginx 提供复用机制减少新分配压力：
- 链表节点优先调用 ngx_chain_get_free_buf() 获取空闲节点，而非每次 ngx_alloc_chain_link()
- 固定长度响应头（如 "HTTP/1.1 200 OK"、"Content-Length: "）采用静态 buffer 池或模块级预分配池，避免 per-request 分配
- 启用 sendfile 或 directio 时，数据绕过用户态 buffer 直达 socket，天然减少中间内存分配
