必须在http入口handler显式检查x-test-flag并用私有key通过context.withvalue注入，grpc需在拦截器中用metadata.fromincomingcontext提取并透传，dao/redis/异步任务等全链路须统一从context读取标识动态路由，否则压测流量将误写主库。
压测流量进了系统，但数据库还是写了主库——说明流量标记没透传到底，或者影子库路由逻辑根本没触发。这不是配置漏了，而是 Go 服务里 context、header、DB 连接池三者没对齐。
Go HTTP 入口如何正确注入和识别压测标识
别依赖中间件自动解析或全局开关。Golang 没有运行时 AOP，必须在最外层 handler 显式检查并塞入 context.Context。
- 检查请求 header 是否含
X-Test-Flag或X-Env-Type: stress，不是靠X-B3-TraceId判断——trace ID 可伪造，且可能被下游覆盖 - 用
context.WithValue(ctx, testKey, true)注入标识，testKey必须是私有变量（避免 key 冲突），不能用字符串字面量 - Nginx 等代理默认截断长 header，若需透传
X-Scene-ID+X-Trace-ID+ 自定义字段，得调大large_client_header_buffers，否则标记在第一跳就丢
gRPC 场景下 metadata 透传为什么总失效
gRPC 的 metadata 不会自动跨 unary 调用传递，不手动读写就会断链。
- 服务端拦截器中必须调用
metadata.FromIncomingContext(ctx)提取X-Test-Flag，再存进新 context；不能只查req.Header（gRPC 没 header） - 客户端发起调用前，得用
metadata.AppendToOutgoingContext(ctx, "X-Test-Flag", "1")，而不是直接改metadata.MD后传参——后者不生效 - 若用了 streaming，需在每个
Send/Recv前重新绑定 context，否则中间某次调用会丢失标记
DAO 层如何基于 context 动态路由到影子库
硬编码 if testFlag { use stress_db } else { use prod_db } 看似简单，但会在 ORM（如 GORM）生成 SQL 时出错——它不知道你要切库，仍按原库名拼表。
- 不要在 SQL 字符串里拼库名前缀（如
"INSERT INTO stress_orders..."），GORM 无法识别，事务、预编译都会崩 - 推荐方式：初始化 DAO 时传入两个
*sql.DB实例（prodDB和stressDB），每次执行前用ctx.Value(testKey)判断，再选对应连接池调用Query/Exec - 若用 GORM，需封装
*gorm.DB，重写Create/Save方法，在内部根据 context 切换底层*sql.DB，否则 GORM 的Session机制会缓存错误连接
Redis 和异步任务里的压测标识为什么总是“消失”
Go 的 goroutine 默认不继承父 context，且 redis-go 客户端不接收 context 外的元信息，这两点一叠加，压测数据必然进错地方。
- 启动 goroutine 前必须显式传入带标识的 context：
go func(ctx context.Context) { ... }(ctx)，不能直接go func() { ... }() - Redis client 封装时，
Get/Set方法签名必须带context.Context参数，并在方法内检查ctx.Value(testKey)；若为压测，则自动将 key 改为"stress:" + key，而非依赖外部拼接 - 日志打点也要从 context 提取标识，否则
log.Printf输出的全是空 trace ID，排查时分不清哪条是压测日志
最易被忽略的一点：所有中间件、SDK、第三方库（比如 Kafka producer、Elasticsearch client）都得走同一套 context 解析逻辑。哪怕只有一处漏掉，压测流量就会在那个节点“脱标”，之后的所有下游都当成生产流量处理——而这种漏点往往藏在封装很深的工具函数里，不会报错，只会悄悄污染数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
