goland 调试的是 go 后端 grpc server，而非前端 grpc-web 请求；请求需经 envoy 转换为 http/2 才抵达后端，断点不命中通常因网关转发失败或路径配置错误。
GoLand 调试 gRPC-Web 项目时，实际调试的是 Go 后端，不是前端请求
gRPC-Web 本身不运行在 Go 进程里——它只是个协议适配层，真正被 GoLand 调试的永远是后端 gRPC server（grpc.NewServer() 启动的那个）。前端发来的 HTTP/1.1 请求，必须经由 Envoy 或其他网关转换成 HTTP/2 后，才抵达你的 Go 服务。所以你在 GoLand 里打断点、看变量、查调用栈，对象始终是 SayHello 这类 RPC 方法的 handler，而不是浏览器里的 grpc.web.Client。
常见错误现象：断点不命中、收到请求但 handler 没进断点、日志里看到 POST /myservice.MyService/SayHello 却没触发任何 Go 代码。这基本说明请求根本没走到你的 gRPC server，卡在网关转发或路径匹配环节。
- 确认 Envoy 的
cluster配置指向的是后端 gRPC server 的真实地址（如grpc-backend:9090），不是它自己暴露给前端的 HTTP/1.1 端口（如:8080） - 检查 Envoy 的路由规则是否匹配前端请求路径：
/myservice.MyService/SayHello必须和 proto 中service MyService和package myservice完全一致（大小写敏感） - GoLand 的 Run Configuration 里，确保启动的是你实现
RegisterMyServiceServer的 main 包，而不是只跑了个空的 HTTP mux
前端请求无法到达 Go 后端？先绕过网关直连验证
当你不确定是前端、网关还是后端出问题时，最有效的方法是跳过 gRPC-Web 流程，用 grpcurl 直接调用 Go 服务。如果 grpcurl -plaintext localhost:9090 myservice.MyService/SayHello 能返回结果，说明 Go 后端完全正常；如果失败，问题一定在 Go 代码或监听配置上。
这时再回 GoLand 查：是否用了 net.Listen("tcp", ":9090") 而不是 http.ListenAndServe；是否漏掉了 pb.RegisterMyServiceServer(s, &server{})；server struct 是否嵌入了 UnimplementedMyServiceServer 避免未实现方法 panic。
-
grpcurl默认走明文（-plaintext），Go 后端若启用了 TLS 但没配证书，会静默拒绝——此时 GoLand 日志里可能只有连接关闭，无明确错误 - 若用
grpc.Dial在本地写个 Go 客户端测试，记得传grpc.WithTransportCredentials(insecure.NewCredentials())，否则默认尝试 TLS 握手 - Envoy 日志级别设为
debug，能直接看到它是否成功将请求转发到后端，以及返回状态码（如503表示 cluster 不可达）
GoLand 里看不到 gRPC-Web 请求的 metadata 或 payload
因为 gRPC-Web 请求在到达 Go 后端前，已被网关解包、base64 解码、HTTP/2 封装——你看到的 ctx 和 req 参数，和原生 gRPC 客户端发来的一模一样。想查原始 HTTP 头（比如 X-User-ID 或 Grpc-Encoding），不能靠 req 结构体字段，得从 metadata.MD 里取，且前提是 Envoy 显式转发了这些头。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
例如前端带了 Authorization: Bearer abc，你需要在 Envoy 配置里加 headers_to_add 或启用 cors filter 并设置 allow_headers，否则 Go 侧 grpc.Peer(ctx) 和 metadata.ExtractIncoming(ctx) 都拿不到。
- Go 代码中获取 metadata 的标准写法是：
md, ok := metadata.FromIncomingContext(ctx)，不是从req字段读 - 若前端用的是
@improbable-eng/grpc-web，它默认把自定义 header 放在extraMetadata选项里，需显式传入 client 构造函数，否则不会发出去 - GoLand 的 Debug 视图里，
ctx变量展开后通常不显示 metadata 内容——得手动执行md.Get("x-user-id")才能看到值
双向流（bidi streaming）在 gRPC-Web 中调试要格外小心
标准 gRPC-Web 协议不支持真正的双向流，前端库（如 grpc-web）只能模拟：用长轮询或 WebSocket 封装单向流，再拼成“伪双向”。这意味着你在 GoLand 里看到的 StreamMessages handler，其 Recv() 和 Send() 调用时机、顺序、并发模型，和原生 gRPC 客户端完全不同。
典型表现：前端发送一条消息后，Go 后端 Recv() 返回 nil，但紧接着 Send() 就报 rpc error: code = Canceled desc = context canceled——这往往是因为前端连接已断开，而网关没及时通知后端。
- 不要在 Go handler 里做长时间阻塞操作（如
time.Sleep(5 * time.Second)），gRPC-Web 网关可能因超时主动关闭连接 - 务必检查 Envoy 是否启用了
grpc_webfilter 的enable_cors和allow_non_standard_methods，否则 OPTIONS 预检失败会导致流式请求直接 404 - 前端调试推荐用浏览器 Network 面板看 WebSocket 帧或长轮询响应体，比依赖 GoLand 断点更直观——毕竟流式交互的“起点”不在 Go 进程里
调试 gRPC-Web 项目时，最容易被忽略的是网关与后端之间的协议边界：GoLand 只管 Go 进程内逻辑，而请求能否进来、header 能否透传、流式是否稳定，全由 Envoy 配置决定。别在 Go 代码里反复改 grpc.ServerOption，先确认网关转发链路是否通畅。
