Go-Micro v4 已于2022年底停止维护，新项目应避免使用，推荐直接采用 gRPC + etcd/Consul + 自定义中间件；老项目升级前需评估是否真需框架抽象，v3 可作为过渡方案。
Go-Micro v4 不再维护，别踩「新项目用 v4」这个坑
Go-Micro 官方在 2022 年底已停止维护 v4，并明确建议迁移到 go-micro/v4 的替代方案（如 micro/micro CLI 工具链或直接用 Go 标准库 + gRPC）。现在新建项目还按老教程拉 github.com/micro/go-micro/v4，大概率会卡在依赖冲突、Context 传参失败、registry 初始化 panic 这几类问题上。
常见错误现象：cannot use service (type *"github.com/micro/go-micro/v4".Service) as type *"go-micro.dev/v4".Service —— 这是模块路径变更导致的跨版本类型不兼容，不是代码写错了，是根本没对齐生态。
- 新项目直接放弃 Go-Micro，改用
google.golang.org/grpc+go.etcd.io/etcd/client/v3（服务发现）+ 自定义中间件，可控性更高 - 老项目要升级，优先确认是否真需要「框架抽象」：多数内部微服务其实只需要 gRPC Server/Client + Consul 注册 + 简单熔断，硬套 Go-Micro 反而增加调试成本
- v4 的
micro.NewService默认启用了过时的http.Transport配置，在 Kubernetes 中容易触发连接复用异常，必须显式覆盖ClientOptions
用 go-micro/v3 跑通一个最小 gRPC 服务的三步法
v3 是最后一个稳定可用的 Go-Micro 大版本，支持 Go 1.16+，适合过渡期快速验证逻辑。它把「服务定义」和「传输实现」拆得比较清楚，但默认仍绑定 Protobuf 和 gRPC。
使用场景：想快速跑通服务注册、调用、健康检查闭环，不涉及 HTTP 网关或消息总线。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 第一步：定义 proto，生成
xxx.pb.go和xxx.micro.go（后者由protoc-gen-micro生成，不是protoc-gen-go） - 第二步：Server 端用
micro.NewService初始化，传入micro.Address("0.0.0.0:8080")和micro.Registry实例；Client 端用micro.NewService+micro.WithRegistry连接注册中心 - 第三步：调用必须走
service.Client().Call，不能直接 new grpc.ClientConn —— 否则绕过 Go-Micro 的负载均衡和重试逻辑，Call内部才真正解析 registry 中的节点列表
性能影响：v3 的 client.Call 默认带 3 次重试 + 指数退避，QPS 高时可能掩盖真实超时，需通过 client.WithRetries(0) 关闭或自定义 selector。
服务注册失败？先检查 etcd / consul 的 endpoint 格式
Go-Micro 的 registry 实现对地址格式非常敏感，尤其是 etcd —— 它要求 endpoint 必须带 http:// 或 https://，且不能有尾部斜杠。写成 "localhost:2379" 或 "http://localhost:2379/" 都会静默失败，日志里只打印 registry: register error: context deadline exceeded。
- etcd 正确写法：
micro.Registry(etcd.NewRegistry(registry.Addrs("http://localhost:2379"))) - consul 正确写法：
consul.NewRegistry(registry.Addrs("127.0.0.1:8500"))（consul 不强制协议头，但端口必须是 HTTP API 端口） - 如果用 Docker Compose，确保服务间网络可达：Go-Micro 进程读取的是容器内 DNS 名（如
etcd:2379），不是宿主机的localhost
兼容性注意：v3 的 etcd registry 依赖 go.etcd.io/etcd/client/v3，和 v4 的 go.etcd.io/etcd/client/v4 不兼容，混用会导致 invalid indirect of clientv3.Client literal 类型错误。
Context 传递中断？所有 handler 必须接收 *micro.Context
Go-Micro 的中间件链（如 auth、trace）靠 *micro.Context 透传数据，但它的类型不是标准 context.Context。如果你在 handler 里写 func(ctx context.Context, req *pb.Request) (*pb.Response, error)，中间件注入的值就拿不到，ctx.Value("trace_id") 返回 nil。
- 正确签名必须是：
func(ctx context.Context, req *pb.Request) (*pb.Response, error)—— 注意第一个参数是标准context.Context，不是*micro.Context - Go-Micro v3 实际会把
*micro.Context转成context.Context再传进来，所以你在 handler 里用ctx.Value拿到的就是中间件塞进去的值 - 容易被忽略的点：gRPC metadata 里的字段（比如
authorization）不会自动转成ctx.Value，得自己写中间件从metadata.MD解析并注入
复杂点在于：一旦你用了自定义 selector 或 transport，micro.Context 的传播行为可能被覆盖，这时候得看具体 transport 的 ClientOption 是否支持 WithBeforeRequest 钩子。
