ngx_http_request_t 是 Nginx 中动态生命周期的 HTTP 请求核心结构体，创建于 ngx_http_create_request()，经初始化、处理、子请求复用后于 ngx_http_free_request() 销毁，字段按阶段有效。
ngx_http_request_t 是 Nginx HTTP 模块最核心的数据结构，代表一次完整的 HTTP 请求上下文。它不是静态定义后就一成不变的，而是在请求生命周期中动态创建、逐步填充、多阶段复用、最终销毁的“活”结构体。理解它的字段含义和何时被赋值、何时被释放，是读懂 Nginx 源码、编写高效模块、排查内存/逻辑问题的关键。
关键字段及其初始化时机该结构体定义在src/http/ngx_http_request.h，大小超过 2KB（含大量指针与缓存字段），但并非所有字段都在请求开始时就有效：connection：指向所属 ngx_connection_t，在ngx_http_init_request()中由事件回调传入并绑定，是请求与 TCP 连接的唯一纽带；
ctx和main_conf / srv_conf / loc_conf：分别存储各模块的请求级上下文和配置指针，在ngx_http_init_request()后期通过ngx_http_create_req_ctx()和配置查找完成初始化；
headers_in和headers_out：分别保存解析后的请求头与待发送响应头；
headers_in在读取并解析完首行+头部后（ngx_http_process_request_headers()）才完整可用；
headers_out则常在 content handler 或 filter 阶段逐步设置；
request_line、uri、args等字符串字段：均为ngx_str_t类型，其data指向 request buffer 中已解析出的原始内存（如request_start~header_end区域），不额外分配；它们在ngx_http_parse_request_line()和ngx_http_parse_header_line()过程中被赋值；
pool：请求专属内存池，在ngx_http_create_request()中创建，贯穿整个请求生命周期，所有 request 级临时分配（如变量值、重写缓冲区、子请求结构）都从此池分配；
生命周期四阶段：创建 → 处理 → 子请求/重定向 → 销毁ngx_http_request_t 的生命周期严格对应 HTTP 请求处理流程，且支持嵌套与复用：创建：由ngx_http_create_request()分配内存 + 初始化基础字段（pool、connection、ctx 置 NULL），此时仅具备骨架；
初始化与解析：进入ngx_http_init_request()，读取并解析请求行、头部，填充 headers_in、uri、args 等，建立模块上下文（ctx）、合并配置；
处理与转发：执行 location 匹配、access/content/handler、output filter 链；若触发内部重定向（ngx_http_internal_redirect()）或子请求（ngx_http_subrequest()），会复用当前 request 结构体的部分字段（如 pool、connection），但重置 uri、args、headers_out 等，并新建子 request 结构体挂到 parent->postponed 链上；
销毁：在ngx_http_finalize_request()调用末尾，执行ngx_http_free_request()，先调用各模块的cleanup回调，再销毁pool（自动释放所有 pool 分配内存），最后释放 request 结构体本身内存；注意：若连接保持长连接，request 销毁但 connection 仍存活，可能用于下一次请求。
易踩坑点：字段有效性 ≠ 生命周期全程有效很多字段只在特定阶段合法，误用会导致段错误或逻辑错乱：request->upstream仅在启用 upstream 模块（如 proxy_pass）后才非 NULL，且在ngx_http_upstream_init_request()中才完成初始化；在 access 阶段直接访问可能为空；
request->variables数组由变量系统懒加载，首次调用ngx_http_get_variable()时才分配并初始化，不能假设其初始就可读写；
request->request_body默认为 NULL，仅当显式调用ngx_http_read_client_request_body()（如需读取 POST body）后才被分配并填充，且该函数异步执行，回调中才能安全使用；
子请求（subrequest）的parent字段指向父请求，但父请求可能早已进入 finalization 阶段，此时访问 parent->headers_out 等字段需加锁或判断状态，否则引发 use-after-free。
调试建议：结合日志与内存断点定位字段状态源码级调试时，不要只看结构体定义，要跟踪字段实际赋值位置：在ngx_http_create_request()下断点，观察初始字段值（多数为 0 或 NULL）；
在ngx_http_process_request_headers()返回前检查headers_in是否已解析完成；
对关键字段（如upstream,request_body）在赋值处（如ngx_http_upstream_init_request,ngx_http_read_client_request_body）加日志或断点，确认是否如期初始化；
使用 AddressSanitizer 编译 Nginx，可捕获对已销毁 request 字段的非法访问；
查看ngx_http_finalize_request中的 cleanup 链表调用顺序，确保自定义 cleanup 回调在依赖资源释放前执行。