gRPC双向流通信成功的关键是：proto中请求和响应均需声明stream、protoc必须同时用--go_out和--go-grpc_out生成代码、Send/Recv须在独立goroutine中异步处理并严格错误检查。
Go 语言实现 gRPC 双向流通信，核心不在“怎么写个循环”，而在于 stream 关键字是否写对、protoc 命令是否生成了正确接口、以及 Send() 和 Recv() 是否在独立 goroutine 中异步处理——三者任一出错，服务端函数根本不会被调用，客户端卡死无报错。
proto 文件里 stream 关键字必须同时出现在请求和响应前
双向流不是靠配置或 runtime 选项启用的，是 .proto 语法硬性规定。漏掉一个 stream，生成的 Go 接口类型就完全不匹配，编译能过但运行时永不触发你的服务端逻辑。
-
rpc Chat(stream Message) returns (stream Message)✅ 正确：参数和返回值都带stream，生成ChatServer类型 -
rpc Chat(Message) returns (stream Message)❌ 错误：变成服务端流，生成的是ChatServerStreamServer，和你写的函数签名对不上 -
rpc Chat(stream Message) returns (Message)❌ 错误：变成客户端流，服务端只能Recv()一次，Send()调用会 panic -
stream必须小写，不能写成Stream；message 类型（如Message）必须显式定义，不能直接用string或bytes
protoc 命令必须同时指定 --go_out 和 --go-grpc_out
只跑 protoc --go_out=. 会生成消息结构体，但没有 XXXClient 和 XXXServer 接口；只跑 --go-grpc_out=. 则找不到 pb.XXXRequest 类型。两者缺一不可。
- 正确命令：
protoc --go_out=. --go-grpc_out=. --go-grpc_opt=paths=source_relative chat.proto - 必须提前安装两个插件：
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest和go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest - 检查生成结果：服务端方法签名应为
func (s *server) Chat(stream pb.ChatService_ChatServer) error，参数类型是pb.ChatService_ChatServer，不是*grpc.ServerStream或手动加的context.Context
服务端 Send/Recv 必须配对错误检查 + 独立 goroutine
Send() 是同步阻塞操作，Recv() 同样可能永久挂起。不检查错误、不分离收发逻辑，goroutine 就会静默卡住，表现为连接数持续上涨但 CPU 很低。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次
Send()后必须检查错误：if err := stream.Send(&res); err != nil { return err }，否则后续调用直接 panic -
Recv()返回io.EOF表示客户端调用了CloseSend()，不是错误，应主动退出循环；其他错误（如网络断开、status.Error）才该return让 gRPC 清理资源 - 不要复用同一个 message 实例反复改字段再
Send()—— proto 序列化内部 buffer 会被覆盖，客户端收到的可能是上一轮数据 - 服务端逻辑若需长时间处理，应在单独 goroutine 中做，主线程只负责
Recv()→ 处理 →Send()流水线，避免阻塞整个流
客户端必须用两个 goroutine 分别处理 Send 和 Recv
在同一个 goroutine 里交替调用 Send() 和 Recv() 是最常见死锁原因：一旦某次 Recv() 阻塞，后续所有 Send() 都发不出去，流彻底僵死。
- 发送 goroutine：监听用户输入或业务事件，每次
Send()前先检查stream.Context().Err() == nil，避免往已失效流写数据 - 接收 goroutine：标准写法是
for { res, err := stream.Recv(); if err != nil { break }; handle(res) }，不能只调一次 - 初始化流时绝不能用
context.Background()，必须用context.WithTimeout()或context.WithCancel()，否则流 hang 住就会永久泄漏 goroutine - 大文件传输时，别
os.ReadFile()后直接Send()，应分块（如 1MB）+io.Copy()+ 显式控制offset和chunk_id，否则极易 OOM
最容易被忽略的是：流的生命周期由 HTTP/2 连接状态隐式绑定，中间件（如 Envoy）、NAT 设备或防火墙可能在无提示下关闭空闲连接，此时 stream.Context().Err() 返回 context.DeadlineExceeded 或 context.Canceled，但服务端若没检查这个状态，就会继续往已断开的流里 Send()，导致资源堆积。真正的健壮性不在“怎么发更多”，而在“什么时候停、怎么安全退出”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
