异步非阻塞本身不透传上下文，需在请求解析、转发、响应各阶段精准捕获与注入；nginx用map或lua提取header并proxy_set_header透传，netty通过channelhandlercontext.attr()绑定，禁用threadlocal以防串扰。
异步非阻塞特性本身不直接“透传动态上下文”，它提供的是高并发、低延迟的调度能力；真正实现上下文透传，依赖的是在事件驱动流程中，对请求生命周期各阶段（解析、转发、响应）进行精准的上下文捕获、携带与注入。Nginx、Netty 或自研代理层均可支持，但方式和粒度不同。
在请求解析阶段提取并绑定上下文
HTTP 请求头（如 X-Request-ID、X-User-ID、X-Tenant）是常见上下文载体。异步代理需在首段 HTTP 头解析完成时，立即提取关键字段，并将其挂载到当前请求对象或 event context 中：
- Nginx 可用 map 指令或 Lua 模块（如 ngx_lua）读取 header，写入 $request_id、$tenant_id 等变量，供后续 proxy_set_header 使用
- Netty 中可在 HttpRequestDecoder 后的 ChannelInboundHandler 里解析 FullHttpRequest，将 header 值存入 ChannelHandlerContext.attr() 绑定的 AttributeKey
- 避免在 body 解析完成前就发起后端连接——否则上下文可能尚未就绪；应等 header 解析完毕再触发 upstream 连接建立
在转发链路中保持上下文连续性
上下文不能只停留在入口，必须贯穿整个代理路径（包括重试、重写、多级路由）：
- 使用 proxy_set_header（Nginx）或 HttpHeaders.set()（Netty）将提取的上下文字段原样或增强后透传至后端，例如：proxy_set_header X-Forwarded-For $remote_addr; 和 proxy_set_header X-Trace-ID $request_id;
- 若涉及跨服务链路追踪（如 OpenTelemetry），需在代理层生成或延续 traceparent header，且确保 span 上下文随异步调用传递（Netty 需结合 ContextPropagation 工具类）
- 对重写路径（如 /api/v1 → /v2）或灰度路由场景，上下文字段应参与决策逻辑（如根据 X-Env=staging 路由到 staging 集群），而非仅做透传
响应阶段反向注入与日志关联
上下文价值不仅在于下发，更在于可观测性闭环：
- Nginx 可通过 log_format 将 $request_id、$upstream_http_x_trace_id 等写入 access log，实现请求全链路可追溯
- Netty 在响应写回前，可从 Channel 属性中取出原始上下文，添加到 response header（如 X-Processed-By: nginx-proxy-v2），便于下游识别代理行为
- 若后端返回了新上下文（如刷新的 token、新生成的 correlation-id），代理层应有选择地覆盖或合并回客户端响应头，而非简单丢弃
注意异步场景下的上下文泄漏风险
事件驱动模型中，线程复用频繁，错误的上下文存储方式会导致串扰：
- 禁止使用 ThreadLocal 存储请求级上下文（Netty 默认不绑定线程，EventLoop 可能复用线程处理多个请求）
- Nginx 的变量作用域天然按请求隔离，相对安全；但 Lua 中若用全局 table 缓存，需配合 set_by_lua_block + request ID 做 key 隔离
- 推荐方案：所有上下文数据绑定到明确生命周期的对象上——Nginx 的 request context、Netty 的 ChannelHandlerContext 或自定义 RequestContext wrapper
