Nginx 通过请求级内存池避免碎片：所有临时内存绑定请求生命周期，禁用 libc 分配，统一使用 r->pool 或 c->pool，小块偏移分配、大块走 large 链表，复用 chain/buf，预分配静态头，监控 anon-rss 与日志验证效果。
核心是让所有临时内存严格绑定请求生命周期，用整批创建销毁代替逐块释放——Nginx 本身不“防碎片”，而是通过不回收来绕过碎片。
用对内存池，禁用 libc 分配
每个 HTTP 请求必须使用 r->pool（请求池）或 c->pool（连接池），所有 headers、buf、结构体都走 ngx_palloc 或 ngx_pcalloc。绝对禁止在模块或 Lua 脚本里调用 malloc、calloc、strdup、asprintf，这些会直接落入 glibc 堆，成为隐式碎片源。
- 结构体优先用 ngx_pcalloc，自动清零，避免脏内存越界
- 小块（≤4095 字节）在线性池中偏移分配，无锁、无元数据
- 大块（如上传 body）走 large 链表，单独 malloc，不污染主池
复用链表与预分配静态头
ngx_chain_t 和 ngx_buf_t 是高频碎片点，反复 new/delete 比分配本身更危险。
- 别每次调 ngx_alloc_chain_link，改用 ngx_chain_get_free_buf(r->pool) 复用空闲节点
- HTTP 状态行、常见 header（如 "Content-Type: text/plain"）用全局静态 buffer，或在模块 postconfiguration 阶段预分配
- 启用 sendfile 或 directio，让文件数据直通 socket，跳过用户态中间 buffer
盯紧第三方模块和 Lua 脚本
多数碎片问题不出在 Nginx 核心，而出在扩展逻辑中。
- 检查 Lua-nginx-module、headers-more 等是否触发 string.format、table.concat 或 Lua GC；改用 ngx.shared.DICT 缓存，而非 Lua table
- Lua 中拼接字符串，优先用预分配 buffer + string.sub，避免动态分配
- 编译时加 -DNGX_DEBUG_MALLOC，运行期用 addr2line 定位非 pool 分配点
验证效果比设计更重要
再严谨的设计也要靠数据确认是否生效。
- 压测中定期执行 pmap -x PID，看 anon-rss 是否阶梯上涨、mmap 区域是否增多
- 查 error log 是否出现 "ngx_chain_get_free_buf: no free buf"，说明 chain 复用机制已失效
- 开启 debug 日志后观察平均池占用率——若普遍低于 1KB，说明小块太碎，正在频繁切新块
