protoc生成的go代码必须与go_package声明严格匹配，否则导致导入失败、类型不识别或跨语言字段丢失；go_package是唯一可信来源，需显式声明完整路径和包名，不可依赖目录推断。
protoc 生成的 Go 代码必须与 go_package 声明严格匹配，否则导入失败、类型不识别、跨语言调用时字段丢失——这不是配置问题，是协议契约断裂。
proto 文件里 go_package 必须写对，且不能只靠目录路径推断
很多人以为把 .proto 放在 user/ 目录下，生成的 Go 包就自动叫 user。错。Go 侧唯一可信来源是 option go_package 的显式声明。
-
option go_package = "./user;user"：生成代码放在当前目录下的user/子目录，包名为user -
option go_package = "github.com/yourorg/app/user;user"：生成代码应放在$GOPATH/src/github.com/yourorg/app/user，包名仍是user，但模块导入路径为github.com/yourorg/app/user - 如果没写
go_package，或写成option go_package = "user"（缺路径），protoc-gen-go会 fallback 到默认行为，但不同版本处理不一致，2026 年主流工具链（v1.31+）直接报错
protoc --go_out 和 --go-grpc_out 参数顺序与插件路径必须同步
旧教程里常见的 protoc --go_out=plugins=grpc:. 已废弃。当前（2026 年）标准方式是分离两个插件，且路径必须显式指定或依赖 $PATH。
-
protoc --go_out=. --go-grpc_out=. user.proto成立的前提是：protoc-gen-go和protoc-gen-go-grpc都在$PATH中，且版本兼容（推荐 v1.31+ / v1.4+） - 若提示
Plugin execution failed: signal: killed或exec: "protoc-gen-go-grpc": executable file not found，说明插件未安装或不在路径中 - 不要混用
google.golang.org/grpc/cmd/protoc-gen-go-grpc和github.com/golang/protobuf/protoc-gen-go—— 后者已归档，仅支持 proto2，且不生成 gRPC 接口
生成的 *_grpc.pb.go 不是“拿来即用”，它只定义接口，不实现业务逻辑
user_grpc.pb.go 里只有 UserServiceServer 接口和 NewUserServiceClient 客户端构造函数，真正的服务逻辑必须另写 struct 实现该接口。
- 服务端必须实现全部 RPC 方法，哪怕只是返回
status.Error(codes.Unimplemented, "") - 方法签名强制带
context.Context第一个参数，第二个参数是请求 message 指针，返回值必须是error；漏掉任一参数或类型不符，grpc.Serve启动时不会报错，但调用时直接返回UNIMPLEMENTED - 客户端调用前必须先建立
grpc.Dial连接，且需传入WithTransportCredentials(insecure.NewCredentials())（开发时）或WithTransportCredentials(credentials.NewTLS(...))（生产）
跨语言调用失败，90% 是因为 message 字段编号或默认值不一致
Python/Java 客户端能连上 Go 服务但收不到字段？不是网络问题，是 Protobuf 编码层不兼容。
- 所有语言共用同一份
.proto文件，但各自生成代码时可能忽略optional或default设置；proto3 中字段无默认值，空字符串、0、false 是合法值，不是“未设置” - 字段编号一旦发布就不能改：重用编号、删字段、换类型都会导致反序列化失败或静默截断
- 如果 Java 客户端发来
name=""，Go 服务收到的是空字符串，不是 nil；想区分“未设”和“设为空”，得用wrapper类型（如google.protobuf.StringValue）或升级到 proto3 的optional（需 protoc v3.15+ + go plugin v1.27+）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
