context.withvalue 不适合传请求 id 做幂等校验，因其只读不可变、不跨进程传递、不参与序列化，grpc/http 传输时丢失；应将 id 放在 header/metadata/请求体中，服务端统一提取。
为什么 context.WithValue 不适合传请求 ID 做幂等校验
因为 context.WithValue 是只读、不可变的，且无法跨进程/网络边界可靠传递——RPC 请求经过中间件、代理或重试后，原始 context 已丢失。更关键的是，它不参与序列化，gRPC 或 HTTP 传输时根本不会带上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须把唯一请求 ID 放在协议层：HTTP header（如
X-Request-ID）、gRPC metadata、或 RPC 请求体字段中 - 服务端入口统一从这些位置提取 ID，**不要**依赖 context 携带的“上游传入值”做校验依据
- 如果用了 gRPC，用
grpc.Peer或metadata.FromIncomingContext读取 metadata；HTTP 服务则从r.Header.Get("X-Request-ID")取
如何生成真正分布式唯一的请求 ID
UUIDv4 看似简单，但存在概率性重复、无序、存储/索引效率低的问题；时间戳+PID 容易在容器重启或多实例下冲突。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用
github.com/google/uuid的uuid.NewSHA1+ namespace + traceID/parentID 拼接，兼顾唯一性和可追溯性 - 高吞吐场景推荐
github.com/sony/sonyflake：基于时间+机器 ID+序列号，生成 int64，天然有序、可排序、占空间小 - 避免在 handler 里临时生成 ID——必须在客户端发起请求前就确定，并透传到底层服务
- 若用 OpenTelemetry，可直接复用
trace.SpanContext.TraceID()字符串（需转为标准格式），前提是全链路已接入
幂等键设计：不能只用 ID，还得加业务维度
只靠全局唯一 ID 校验，会导致同一用户连续提交两个合法但语义不同的请求被误拒（比如两次不同金额的充值）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 幂等键 =
"{request_id}:{user_id}:{business_type}:{amount_hash}"，其中amount_hash是关键参数的 SHA256 摘要 - 对写操作（如创建订单），幂等键必须包含所有影响最终状态的输入字段，否则缓存击穿后会写出脏数据
- Redis 中用
SET key value EX 3600 NX原子写入；value 推荐存json.Marshal(map[string]interface{}{"ts": time.Now().Unix(), "req": req})，便于后续审计 - 注意：如果业务允许“相同请求多次生效”，那就不该用幂等，而是用状态机控制流转（比如“待支付→已支付”不可逆）
超时重试时的 ID 透传与服务端去重时机
客户端重试没带原 ID，或服务端在 DB 写入成功但响应丢失后没做幂等检查，都会导致重复执行。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端（如
net/http）重试前，必须确保X-Request-ID不变；gRPC 客户端用grpc.WithBlock()+ 自定义 retry interceptor 显式携带 metadata - 服务端应在**反序列化后、业务逻辑前**就完成幂等键查询和短路返回，而不是等 DB 插入失败才拦截
- 数据库唯一约束（如
UNIQUE(request_id)）是兜底，不是主力——它只能防写入重复，不能防中间态（如发消息、扣库存）重复执行 - 如果用了消息队列（如 Kafka），消费者侧也得按
request_id做本地缓存去重，因为消息可能重复投递
最常被忽略的一点：幂等键的 TTL 必须大于业务最长处理时间 + 最大重试窗口。设成 1 小时很常见，但如果一个订单审核要走人工，实际耗时 3 天，那这个键早过期了，重试照样穿透。别只看文档示例值。
