proto文件须统一放在独立proto/目录并显式指定-I路径，生成代码需匹配go_package路径，gRPC服务需手动注册，跨服务调用必须透传context deadline与标准status错误，proto升级要保障字段兼容性。
proto 文件必须放在独立目录且显式 import
Go-protobuf 不会自动扫描整个项目找 .proto 文件，你得明确告诉 protoc 哪里找、生成到哪。常见错误是把 api.proto 直接丢在 service 目录下，结果 protoc 找不到依赖或生成路径混乱。
- 推荐结构：
proto/目录统一存放所有.proto，例如proto/user/v1/user.proto - 生成 Go 代码时，用
-I proto/指定 import 路径，不是当前目录 -
import "google/protobuf/timestamp.proto";这类标准库引用，需确保protoc-gen-go安装时附带了google/protobuf/路径（通常go install google.golang.org/protobuf/cmd/protoc-gen-go@latest自带） - 如果用了
option go_package = "github.com/yourorg/yourrepo/proto/user/v1";，生成的 Go 包路径必须和该字符串完全一致，否则import会失败
生成代码后要手动注册 gRPC Server 和 Client
Go-protobuf 只生成数据结构和接口定义，RegisterUserServiceServer 和 NewUserServiceClient 这些函数不会自动生效——你得自己调用。
- 服务端：在
main.go中初始化grpc.Server后，必须显式调用userpb.RegisterUserServiceServer(srv, &UserServiceImpl{}) - 客户端：不能直接 new struct，要用
userpb.NewUserServiceClient(conn)获取 client 实例 - 注意
UserServiceImpl必须实现userpb.UserServiceServer接口，方法签名要严格匹配（包括上下文参数、error 返回位置） - 若用 Wire 或其他 DI 工具，记得把
*grpc.ClientConn和生成的 client 注入链路，而不是 raw struct
跨服务调用时 context deadline 和错误码必须透传
微服务间调用不是本地函数调用，gRPC 的 context.Context 是唯一携带超时、取消、元数据的载体；错误也得用标准 status.Code，否则下游无法区分是网络失败还是业务拒绝。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 客户端发起调用时，务必用
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，别用context.Background() - 服务端处理中不要忽略传入的
ctx，比如 DB 查询、HTTP 外部调用都要带上它 - 返回错误时，优先用
status.Errorf(codes.NotFound, "user %s not found", id)，而不是fmt.Errorf("not found") - 中间件（如 auth、logging）若修改
ctx（如加 value），需确保不覆盖原始 deadline 或取消信号
proto 升级时字段兼容性比语法糖更重要
Go-protobuf 本身不校验字段变更是否破坏兼容性，但 gRPC runtime 会按 tag 解析二进制流——加字段可以，删字段或改类型大概率导致 panic 或静默数据错乱。
立即学习“go语言免费学习笔记（深入）”；
- 永远用
optional或保留字段（reserved 3;）为未来留空位 - 重命名字段？不行。只能新增字段 + 注释说明旧字段已弃用
- 枚举值追加可以，但删除或重排序号会导致反序列化失败（即使名字一样）
- 测试环节必须跑通旧 client 调新 server、新 client 调旧 server 的双向兼容用例，光看编译通过没用
真正麻烦的从来不是生成代码那几行命令，而是字段语义变更时没人翻 proto 历史记录，上线后某条链路突然 decode 出空指针。
