必须在Gin入口中间件统一提取X-Test-Flag等多字段并归一化校验，用私有key通过context.WithValue注入，同时显式透传至HTTP header和gRPC metadata，确保DAO层据此动态路由至影子库。
如何在 Gin 中间件里安全提取并透传压测标识
压测标识不能只靠 X-Test-Flag 或 X-Env-Type 单一 header 判断，更不能在业务 handler 里零散解析。必须在入口中间件统一拦截、校验、注入 context，并确保下游调用（HTTP + gRPC）都能拿到它。
常见错误是只检查 header 是否存在，却忽略大小写、空格、伪造风险；或者用 c.GetHeader("X-Test-Flag") == "1" 这种裸比较，没做 trim 和非空判断，导致 " 1 " 或 "true" 被漏掉。
- 使用
strings.TrimSpace(strings.ToLower(c.GetHeader("X-Test-Flag")))统一归一化后再比对 - 必须同时检查
X-Pressure-Test、X-Env-Type、Cpts-X-Test等多个常见压测头，避免因压测工具差异导致漏标 - 提取后立即用
c.Set("is_stress", true)写入 context，并通过c.Request = c.Request.WithContext(context.WithValue(c.Request.Context(), testKey, true))向下透传 - 禁止在中间件里直接修改
c.Request.Header——Gin 的Request是只读的，改了也不生效；要用metadata.AppendToOutgoingContext（gRPC）或手动构造下游 HTTP client req.Header
为什么 Gin 中间件必须同时处理 HTTP 和 gRPC 的透传路径
微服务链路里，一个 Gin 服务既可能是 HTTP 入口，也可能作为 gRPC 客户端调用下游。若中间件只处理 HTTP header，gRPC metadata 就会断链，下游服务收不到压测标识，直接把压测请求当生产流量处理。
典型现象：压测时订单创建成功，但库存扣减失败——因为库存服务没识别出这是压测流量，拒绝写影子库，而上游已把订单落库了。
- Gin 本身不处理 gRPC，但你的服务很可能用
grpc-go调用其他服务，所以中间件需在c.Next()前准备好 metadata - 推荐做法：在压测中间件末尾，调用
metadata.Pairs("x-test-flag", "1", "x-scene-id", sceneID)构造元数据，再用metadata.NewOutgoingContext(c.Request.Context(), md) - 若下游是 HTTP 服务，需在发起
http.NewRequest后显式设置：req.Header.Set("X-Test-Flag", "1")，别指望中间件自动帮你塞 - Nginx 默认限制 header 大小为 4KB，若透传过多字段（如带完整 trace 链路树），可能被截断；建议只透传必要字段：
X-Test-Flag、X-Scene-ID、X-B3-TraceId
压测中间件里如何避免污染真实数据库连接池
中间件本身不执行 DB 操作，但它决定了后续 DAO 层该用哪个连接池。如果中间件没把压测标识可靠地写进 context，DAO 层就无法动态路由到 stress_db，结果就是压测数据直写生产表。
最危险的做法是：在中间件里读取 header，然后全局切换一个变量（如 globalIsStress = true），这在高并发下必然出现竞态——goroutine A 刚设为 true，B 就覆盖成 false。
- 必须用
context.WithValue，且 key 类型不能是 string，得是私有类型（如type stressKey struct{}），防止被其他中间件误覆写 - 中间件内不要做任何 DB 初始化或连接池切换逻辑，只负责“声明”——把标识放进去，让 DAO 层自己根据 context 做判断
- 测试时务必验证：在 handler 里打印
c.Value(testKey)，确认值是true；再在 DAO 层加日志，确认走的是stress_db.Query而非prod_db.Query - 若用了 GORM，别试图在中间件里调用
db.Session(&gorm.Session{Context: c.Request.Context()})——GORM 的 Session 不会自动继承 context.Value，仍需在每个查询前手动传 context
为什么不能把压测逻辑写在 logger 或 recovery 这类通用中间件里
logger 和 recovery 是 Gin 的内置中间件，它们执行顺序固定、职责单一。把压测标识解析塞进去，会导致两个问题：一是违反单一职责，二是破坏中间件链的可预测性——别人加个新中间件，可能意外覆盖或干扰压测逻辑。
真实踩坑案例：某团队把 X-Test-Flag 解析放在 gin.Logger() 之后，结果发现部分请求没被标记；排查发现是某个鉴权中间件调用了 c.Abort() 提前退出，logger 虽然执行了，但压测中间件根本没跑。
- 压测中间件必须注册在所有业务中间件之前，且位置固定（通常紧接在
gin.Logger()后、gin.Recovery()前） - 命名要明确，比如
StressHeaderMiddleware，别叫CommonMiddleware或BaseMiddleware，否则后期维护者不知道它干啥 - 必须配合单元测试：用
gin.CreateTestContext构造带X-Test-Flag: 1的请求，断言c.Value(testKey) == true，且c.Request.Header.Get("X-Test-Flag")未被篡改 - 线上灰度时，建议加一个兜底开关：当
X-Test-Flag缺失但请求来自压测机 IP 段时，也按压测流量处理，避免 header 丢失导致全链路中断
压测中间件真正的难点不在代码量，而在它必须成为整个链路的“守门人”：header 解析要防伪造、context 传递要防丢失、下游透传要防断裂、DB 路由要防误切。任何一个环节松动，压测数据就可能流进生产表——而这种污染往往在压测结束几小时后才被发现。
