grpc流式调用中context不会自动续传，因每个消息帧共享同一http/2 stream且context.context不随消息更新；服务端须每次recv前检查stream.context().err()，客户端需正确传入带超时/取消的ctx并用calloption传metadata。
gRPC流式调用中Context不会自动续传
流式 RPC（如 ServerStreaming、BidirectionalStreaming）的每个消息帧不是独立请求，而共享同一个底层 HTTP/2 stream；但 Go 的 context.Context 本身不随每条消息自动更新或重注入——你传给 stream.Send() 或 stream.Recv() 的 ctx 是初始调用时的那个，后续无法动态变更。这意味着：如果初始 ctx 带了超时，它从第一个 Recv 开始倒计时；如果中间需要延长、取消或注入新值（比如新 traceID 分片），必须手动干预。
服务端如何在流中安全读取和响应Context变化
服务端不能只依赖初始 ctx 的 Done() 通道来判断整个流是否该终止——因为流可能持续数分钟，而客户端可能中途 cancel 上游 context，此时服务端需立刻感知并停止发送。关键点在于：
-
stream.Context()返回的是与当前 stream 绑定的 context，它会自动继承客户端断连、超时、cancel 等信号，且比初始 handler ctx 更精准 - 每次调用
stream.Recv()前，务必检查stream.Context().Err()，而不是缓存初始 ctx - 若需在流中透传新 metadata（如客户端中途发来新的
tenant-id），必须用stream.SetHeader()或stream.SendHeader()显式发送，服务端通过stream.Header()获取——但注意：Header 只能发一次，且仅在 stream 开始时有效 - 真正需要“动态上下文”的场景（如权限变更），应设计为业务消息携带元数据字段，而非依赖 context 透传
客户端发起流式调用时Context该怎么传
客户端调用 client.StreamMethod(ctx, opts...) 时传入的 ctx 会绑定到整个 stream 生命周期，但有三个易错点：
- 别用
context.Background()—— 它无取消能力，一旦流卡死，goroutine 无法回收 - 超时必须用
context.WithTimeout(ctx, 5*time.Minute)，且defer cancel()要放在stream.CloseSend()之后，否则可能提前中断流 - 若需在流中追加 metadata（如重试时带上 retry-count），不能改写原始 ctx，而应调用
stream.SetTrailer(metadata.MD)发送 trailer（仅服务端可读，且非所有语言支持）；更可靠的做法是把这类信息作为业务 payload 字段发送
为什么流式通信中metadata.FromIncomingContext常返回nil
不是所有流式调用的 ctx 都带 metadata，常见原因：
- 客户端没用
grpc.Metadata(md)作为CallOption传入流方法，而是错误地用了metadata.AppendToOutgoingContext()—— 后者对流式调用无效，只影响 unary - 服务端拦截器未正确 wrap stream，比如写了
handler(srv, ss)却漏掉ss.ServerStream的包装，导致 metadata 未注入到 stream.Context() - 单元测试中直接用
context.Background()构造 stream，没模拟 gRPC transport 层解析过程
验证方式：在服务端 handler 开头打印 md, ok := metadata.FromIncomingContext(stream.Context())，ok 为 false 就说明 metadata 没进来——这时别硬取，应退回到消息体解析逻辑。
