真正隔离的端到端grpc测试应使用bufconn内存管道，client需配withcontextdialer+bufconn.dialer，server注册必须用指针接收者并调用srv.serve(lis)，handler须监听ctx.done()验证取消。
怎么在 Go 里不启真实 server 就测 gRPC 接口
直接用 grpc.Dial 连本地端口，本质还是依赖运行中的服务，没法做纯单元测试。真正隔离的端到端测试，得用 bufconn —— 它提供内存管道（in-memory listener），Client 和 Server 都走这个管道，零网络、无端口冲突、启动快。
常见错误是把 bufconn.Listen 返回的 *bufconn.Listener 直接传给 grpc.NewServer()，这没问题；但 Client 端用 grpc.Dial 时，必须配 grpc.WithContextDialer + bufconn.Dialer，否则 Dial 会卡住或报 connection refused。
-
bufconn不是标准库，需go get google.golang.org/grpc/x/net/bufconn - Listener 的 buffer size（如
bufconn.Listen(1024 * 1024)）要大于单次请求/响应体，否则可能阻塞或丢数据 - Server 必须调用
lis.Close()或用defer lis.Close()，否则 test goroutine 可能 leak
如何让 mock client 发出带 metadata 和 timeout 的真实调用
gRPC 的 context.WithTimeout 和 metadata.MD 是透传到 server 端的，但很多人只在 client 端设了 context，却没在 server handler 里显式读取 metadata.FromIncomingContext 或检查 ctx.Err() == context.DeadlineExceeded，导致“超时没生效”或“header 拿不到”。
实操上，client 调用前构造 context 即可，不用改 stub：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
md := metadata.Pairs("auth-token", "test-123")
ctx = metadata.InjectOutgoingContext(ctx, md)
<p>resp, err := client.SayHello(ctx, &pb.HelloRequest{Name: "Alice"})
- metadata key 自动转小写，
"Auth-Token"会被变成"auth-token" - timeout 是对整个 RPC 调用生效，不是单个 send/recv；如果 handler 里有阻塞操作（如 sleep），必须主动 select ctx.Done()
- server 端用
metadata.FromIncomingContext(ctx)拿 metadata，不是FromOutgoingContext
为什么 TestServer 注册 service 后调用返回 UNIMPLEMENTED
典型现象：server 启起来了，client dial 成功，但一调就报 rpc error: code = Unimplemented desc = method XXX not implemented。根本原因不是函数没写，而是注册顺序或对象不对 —— pb.RegisterXXXServer 第二个参数必须是实现了对应 interface 的 struct 实例，且该 struct 方法必须是 **指针接收者**。
比如你定义了：
type HelloService struct{}
func (h HelloService) SayHello(...) {...} // ❌ 值接收者 → 不满足 pb.HelloServiceServer 接口
正确写法是：
func (h *HelloService) SayHello(...) {...} // ✅ 指针接收者
...
srv := grpc.NewServer()
pb.RegisterHelloServiceServer(srv, &HelloService{}) // 注意这里传指针
- Go 接口实现是隐式的，编译器不会报错，但 runtime 会拒绝注册值接收者的方法
- 如果用 embed 方式组合多个 service，确保每个嵌入字段都是指针类型，且外层 struct 方法也用指针接收
- 注册后别漏掉
srv.Serve(lis)，否则 listener 不会处理连接（哪怕 bufconn 也是）
如何验证 server 端是否真的收到了 client 的 cancellation
单纯看 client 报 context canceled 不够，得确认 server handler 是否及时退出、有没有资源泄漏。最可靠的方式是在 handler 里加 select 监听 ctx.Done()，并在 case 中打日志或设标志位。
例如：
func (s *HelloService) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloResponse, error) {
done := make(chan struct{})
go func() {
<-ctx.Done()
log.Println("server received cancellation:", ctx.Err())
close(done)
}()
// 模拟耗时操作
select {
case <-time.After(2 * time.Second):
return &pb.HelloResponse{Message: "hello"}, nil
case <-done:
return nil, status.Error(codes.Canceled, "canceled by client")
}
}
- 不要在 handler 里直接
time.Sleep，它不响应 cancel；必须用select+ctx.Done() - server 返回
codes.Canceled后，client 的err会是context.Canceled，但前提是 server 显式返回，不是 panic 或 panic recover - 如果 handler 启了 goroutine 且没传 ctx，cancel 不会自动传播，得手动监听并 stop
测试里最容易被忽略的，是 bufconn listener 的生命周期和 server.Serve 的 goroutine 管理 —— 它既不能提前 close，也不能忘记 stop，否则 test 会 hang 或 panic。
