用unary传大文件必崩，必须选对流类型、显式调大缓冲、手动分块读写、避免复用proto实例；stream关键字位置决定流类型，错写将导致接口完全不可用。
直接结论：用 unary 传大文件必崩，必须选对流类型、显式调大缓冲、手动分块读写、避免复用 proto 实例——否则不是卡死就是 oom。
proto 中 stream 关键字位置写错，生成的 Go 接口就完全不能用
gRPC 流类型不靠注释或文档判断，只由 stream 在 rpc 声明中的位置硬决定。写错一个字，protoc 生成的 Go 接口方法名、Send/Recv 能力、甚至是否支持流都会错乱：
- 服务端流：必须是
rpc GetLogs(LogRequest) returns (stream LogResponse)—— 客户端调Recv()多次，服务端只调一次Send()启动流 - 客户端流：必须是
rpc Upload(stream Chunk) returns (UploadResult)—— 客户端反复Send()，服务端等收完才Send()一次结果 - 双向流：必须是
rpc Sync(stream FileChunk) returns (stream SyncAck)—— 双方各自Send()/Recv()，互不阻塞 - 常见错误：
rpc Upload(stream Chunk) returns (UploadResult)写成rpc Upload(Chunk) returns (stream UploadResult)，结果生成的是服务端流接口，但业务需要客户端流，调Recv()永远等不到数据
客户端分块发送时，Send() 不是“发完就完”，必须检查返回 err
Send() 是同步阻塞调用，网络中断、流关闭、消息超限都会立刻返回 error。不检查就继续循环，下一次 Send() 会 panic 或静默失败：
- 别用
os.ReadFile()一次性读整个文件再塞进Send()—— 这等于又回到 Unary 模式，几十 MB 就触发 OOM - 正确做法：开固定 buffer（如
make([]byte, 256*1024)），用bufio.NewReader(file).Read()分块读，每次构造新*pb.Chunk实例（别复用！）再Send() - 必须在每次
Send()后判断：if err != nil { return err }；遇到io.EOF才退出循环 - buffer 太小（如 4KB）导致 gRPC header 开销占比飙升；太大（如 2MB）易触达默认 4MB
maxReceiveMessageSize限制
服务端接收流不能靠 for range stream.Recv()，得用带超时的 RecvMsg()
for range stream.Recv() 看似简洁，但底层是 channel 风格封装，一旦某次 Recv() 卡住（如网络抖动、中间件断连），整个 goroutine 就永久挂起，无法响应超时或心跳：
- 正确模式：用
select+stream.RecvMsg(&msg)，配合context.WithTimeout()控制单次等待时长（建议 ≥30s） - 每个
Chunk必须含offset和单调递增的seq字段，服务端用map[int]*pb.Chunk缓存乱序块，收到seq == 0才初始化临时文件 - 收到 chunk 后别直接拼内存，立刻
os.WriteAt(data, offset)落盘；校验checksum失败则返回status.Error(codes.Aborted, "checksum mismatch") - 别在
Recv()循环里做 fsync —— 频繁刷盘会拖垮吞吐；可每 10MB 或 5 秒 batch sync 一次
不显式调大 grpc.MaxRecvMsgSize 和 grpc.MaxSendMsgSize，4MB 就断连
gRPC 默认收发消息上限是 4MB（4194304 字节），超过直接报错：rpc error: code = ResourceExhausted desc = grpc: received message larger than max (X vs 4194304)。这不是配置问题，是硬限制：
- 客户端 dial 时必须加选项：
grpc.Dial("...", grpc.WithDefaultCallOptions(grpc.MaxSendMsgSize(64 * 1024 * 1024))) - 服务端
grpc.NewServer()也要加：grpc.MaxRecvMsgSize(64 * 1024 * 1024) - 如果走 Nginx/Envoy，还得同步调大其 HTTP/2 frame size 和 timeout（默认常为 60s），否则传输到 70% 就被中间件静默断开
- 别信“调大 buffer 就能自动分片”——gRPC 不会帮你切包，chunk size 是你代码控制的，buffer 和 max msg size 是两回事
最易被忽略的一点：所有流式调用都必须复用 *grpc.ClientConn，绝不能每次上传都 grpc.Dial() 新建连接。连接建立开销大，且 HTTP/2 流控状态无法继承，频繁新建会导致伪超时和连接雪崩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
