grpc客户端流需先获取clientstream接口实例，仅调用sendmsg多次发送数据，最后必须显式调用closesend；sendmsg阻塞且非线程安全，须串行调用并逐次检查错误，避免复用stream或并发发送。
gRPC客户端流怎么写：先看ClientStream接口本质
Go 的 gRPC 客户端流不是“发一串数据就完事”，而是你拿到一个实现了 ClientStream 接口的对象，它同时支持发送（SendMsg）和接收（RecvMsg）——但**流式发送场景下，你通常只调用 SendMsg 多次，最后调用 CloseSend 告诉服务端“发完了”**。别误以为要自己起 goroutine 循环读响应，除非服务端真有回传流。
- 必须显式调用
stream.CloseSend()，否则服务端永远等不到 EOF，可能卡住或超时 -
SendMsg是阻塞的，如果服务端处理慢、网络卡或背压大，它会卡在这儿——别在循环里无脑狂 send - 错误得在每次
SendMsg和最终RecvMsg后检查，SendMsg失败不意味着流已断，但大概率后续也发不出去了
常见错误：SendMsg 报 rpc error: code = Unavailable desc = transport is closing
这通常不是网络问题，而是你没管好连接生命周期。最常踩的坑是：复用了一个已经 CloseSend 过、或底层连接因超时/服务重启已断开的 ClientStream。
- 每个流请求应新建 stream，不要缓存或复用
ClientStream实例 - 别在 stream 上并发调用
SendMsg—— 它不是线程安全的；如需多路数据，自己加锁或用 channel 串行化 - 如果服务端要求严格顺序，而你在 goroutine 里 send，极易触发该错——
SendMsg必须串行调用
怎么控制发送节奏：别硬扛，用 context + 超时 + 限速
客户端流一旦开始，就进入了“半长连接”状态。没有内置节流，全靠你控制发送频率和单次负载大小。发太快，服务端 OOM；发太慢，连接被中间件（如 nginx、istio）主动 kill。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 给每个
SendMsg加独立context.WithTimeout(ctx, 5*time.Second)，避免一次卡死拖垮整条流 - 批量发送比逐条更稳：把 10 条小消息合并成一个含
[]*pb.Item字段的 message，减少序列化/网络开销 - 若数据源来自文件或 channel，别用
for range直接 send，中间插time.Sleep(10 * time.Millisecond)或用 token bucket 控制速率
服务端没响应？先确认它是不是真支持客户端流
看 proto 文件里方法定义：必须是 rpc Upload(stream Chunk) returns (Result) 这种形式（左边带 stream，右边不带）。如果右边也带 stream，那就是双向流，客户端也得 RecvMsg；如果右边没 stream，那服务端理应返回单个响应，但**它可能延迟返回——直到收到 CloseSend**。
- 用
grpcurl测试：运行grpcurl -plaintext -import-path ./proto -proto upload.proto localhost:8080 pb.Upload看是否能交互式输入多条 JSON - 服务端日志是否打印出 “received first message”、“got CloseSend”、“started processing” —— 没这些，大概率客户端根本没发出去，或服务端路由错了
- Wireshark 抓包看 HTTP/2 DATA 帧是否发出，比盲猜快得多
事情说清了就结束。客户端流最麻烦的从来不是语法，而是你得同时当好生产者、节拍器和故障观察员。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
