go-micro v4 已归档且不兼容新 Go 版本，必须显式配置服务名、注册中心、传输等组件，否则静默失败；推荐改用 Kitex 或原生 gRPC+etcd。
别用 go-micro 搭企业级微服务框架——它已归档、不兼容新 Go 版本、注册中心静默失效、类型系统断裂，强行用只会拖慢交付。
go-micro v4 报 no service name 或 no registry configured 怎么办
这不是配置漏了，是 v4 彻底废除了隐式默认值。所有核心组件必须显式传入：micro.Name("user-srv")、micro.WithRegistry(etcd.NewRegistry())、micro.WithTransport(grpc.NewTransport()) 缺一不可。
- 服务名只允许小写字母、数字、短横线（
user-srv✅，user_service❌，UserSrv❌） -
micro.NewService()必须在service.Init()之前完成全部选项注入；Init()只解析 flag/env，不初始化 registry/broker/transport - 没配 registry 时，
micro.NewClient()默认直连localhost:8080，不是 bug，是设计上把“是否走服务发现”当作显式开关
proto 生成后调用总失败，client.Call 不生效
直接 new grpc.ClientConn 绕过了 go-micro 的 selector、重试、负载均衡逻辑，看似能通，实则失去微服务治理能力。
- 必须走
service.Client().Call(ctx, req, rsp)，且 client 初始化时要传micro.Registry(service.Registry())，确保和 server 共享同一 registry 实例 - v4 默认重试 3 次 + 指数退避，高 QPS 场景下会掩盖真实超时，建议显式加
client.WithRetries(0) - 跨语言调用（如 Python micro service）必须加
micro.WithContentType("application/json")，否则默认用 protobuf+binary 编码，对方解不开
插件注册了但没生效，logger/broker/transport 都不工作
v4 的插件系统只负责“发现”，不负责“激活”。注册名字只是 ID，框架不会按名自动装配。
立即学习“go语言免费学习笔记（深入）”；
-
plugin.WithName("mylogger")只是起个标识符，真正生效得靠micro.WithLogger(myLogInstance)显式传入实现了logger.Logger接口的实例 -
Broker、Transport、Codec不再从环境变量（如MICRO_BROKER=nats）自动读取，v4 只认MICRO_REGISTRY这类基础项，其余都得自己桥接 - 在
service.Init()之后才 newnats.NewBroker()并试图赋值给 options，完全无效——options 是只读快照，改了不生效
现在新建项目还拉 github.com/micro/go-micro/v4，大概率卡在依赖冲突、Context 传参失败、registry 初始化 panic 上。模块路径已变（go-micro.dev/v4 vs github.com/micro/go-micro/v4），类型不兼容不是代码写错了，是根本没对齐生态。复杂点在于：你得先判断自己到底需不需要框架抽象——多数内部微服务，只需要 google.golang.org/grpc + go.etcd.io/etcd/client/v3 + 自定义中间件，可控性更高，调试成本更低。
