必须在gin handler入口显式检查x-test-flag并用私有key通过context.withvalue注入ctx，再调用c.request.withcontext()更新请求上下文，确保dao、grpc、http下游调用均基于该ctx读取标识。
HTTP入口如何手动注入X-Test-Flag并写入context
压测流量识别必须从第一个接收请求的 Gin handler 开始，不能依赖中间件自动补全或 trace ID 推断。Gin 没有内置的“压测上下文”机制，必须显式用 context.WithValue 注入标识。
常见错误是只检查 header 但没存进 context，导致下游 DAO 或 gRPC 调用拿不到判断依据；或者用了 c.Set("test_flag", true)，但这个只在 Gin Context 生效，无法穿透到 http.Client 或数据库操作使用的标准 context.Context。
- 在入口 middleware 中读取
c.Request.Header.Get("X-Test-Flag") == "1"或X-Env-Type: stress - 用
ctx := context.WithValue(c.Request.Context(), testKey, true)替换原 request context - 调用
c.Request = c.Request.WithContext(ctx)确保后续所有操作（包括中间件、handler、defer）都基于新 context - 不要用字符串字面量做 key，定义全局变量
var testKey = struct{}{}避免 key 冲突
gin.Context 和标准 context.Context 怎么桥接才不丢标记
Gin 的 c.Request.Context() 是标准 context.Context，但 c.Next() 后续逻辑若直接用 c.Request.Context() 而非你刚写入的 ctx，标记就失效了。很多开发者误以为 c.Set() 或中间件里改了 c.Request 就万事大吉，其实没覆盖全部路径。
关键点在于：所有需要感知压测的组件（DB 查询、Redis 调用、下游 HTTP/gRPC 请求）都必须基于 c.Request.Context() 构建，而这个 context 必须是你注入过标记的那个。
- 务必在 middleware 开头就执行
c.Request = c.Request.WithContext(newCtx) - 下游 HTTP client 调用时，用
req = req.WithContext(c.Request.Context())显式传入 - gRPC client 调用前，用
metadata.AppendToOutgoingContext(c.Request.Context(), "X-Test-Flag", "1") - DAO 层方法签名必须带
ctx context.Context参数，内部通过ctx.Value(testKey)判断路由逻辑
header 透传时 Nginx 和 Gin 的大小限制怎么绕过
X-Test-Flag 本身只是个开关字段，但有些团队会往 header 塞 JSON、base64 编码的测试上下文，结果被 Nginx 拦截返回 400 —— 因为默认 large_client_header_buffers 是 4KB，且 Gin 默认不限制 header 大小，但实际链路中 Nginx 是第一道关卡。
真实压测场景下，你只需要一个不可伪造、不可绕过的业务标识，不是完整上下文。额外信息（如影子库名、mock 策略）应由服务端根据环境配置或注册中心动态决定，而非靠 header 传递。
- 只透传纯文本标识：
X-Test-Flag: 1或X-Env-Type: stress，长度控制在 20 字符内 - Nginx 配置中确认
large_client_header_buffers 4 8k;（足够容纳多个标准 trace header + 压测标） - 禁止在 header 里塞
X-Stress-Context类字段；如有必要，走独立的压测元数据服务异步拉取 - Gin 中用
c.Request.Header.Del("X-Stress-Context")主动清理非法字段，避免污染下游
为什么不能用 trace ID 当压测判断依据
很多团队图省事，看到请求带 X-B3-TraceId 或 traceparent 就当成压测流量处理，结果线上数据被污染。trace ID 可被复用（比如重试）、可被伪造（curl 手动加 header）、也可来自非压测路径（比如监控探针、日志采集器发起的健康检查）。
真正的压测标识必须满足三个条件：入口强校验、不可绕过、业务语义明确。它不是追踪系统的一部分，而是压测治理系统的独立信令。
-
X-B3-TraceId是链路追踪字段，用途是串联日志和 span，不是权限或路由开关 - 必须有独立字段如
X-Test-Flag，且只在压测网关或入口 LB 上注入，后端服务不做生成逻辑 - 所有中间件、DAO、client 层都只认这个字段，
ctx.Value(testKey) != nil是唯一可信判断条件 - 如果用了 OpenTelemetry，注意
otelgin.Middleware不会自动透传X-Test-Flag，仍需你自己写 middleware 补上
context.Context 替换时机不对，以及 downstream client 调用时忘了把新 context 传进去——这两个点一漏，整条链路就断了。
