go-micro v4 已归档且不兼容新 Go 版本，必须显式配置服务名、注册中心等组件，否则静默失败；推荐改用 Kitex 或原生 gRPC+etcd。
别再用 go-micro 了——它已归档、不兼容新 Go 版本、生态断裂，强行使用只会拖慢交付节奏。
go-micro v4 报 no service name 或 no registry configured 怎么办
这不是配置漏了，是框架设计变了。v4 彻底废除了隐式默认值，所有核心组件必须显式传入。
-
micro.NewService()必须带micro.Name("user-srv")，服务名只允许小写字母、数字、短横线，user_service或UserSrv都会静默失败 - 注册中心不再自动加载，得手动
go get github.com/micro/go-micro/v4/registry/etcd，再传micro.WithRegistry(etcd.NewRegistry()) -
service.Init()不负责初始化 registry/broker/transport，只解析 flag 和 env；这些组件必须在micro.NewService()阶段就塞进去，否则日志里只有no registry configured这种模糊提示，没报错但就是不注册
micro.NewClient 默认连 localhost:8080 的真相
Client 默认 transport 是 HTTP，且未配 registry 时，它压根不查服务发现列表，而是硬编码直连 localhost:8080 —— 这不是 bug，是设计上把“是否走注册中心”当作显式开关。
- 想走服务发现：初始化 client 时必须传
micro.Registry(service.Registry())，确保和 server 用的是同一个 registry 实例 - 想直连调试地址：用
micro.WithAddress("10.0.1.5:9090")，此时 registry 配置会被忽略 - 跨语言调用（比如 Python 服务）必须加
micro.WithContentType("application/json")，否则默认用 protobuf+binary 编码，对方解不开
插件注册了但没生效？你可能误解了 v4 的插件模型
v4 的插件系统只负责“发现”，不负责“激活”。注册名字只是标识符，框架不会按名自动装配。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
plugin.WithName("mylogger")只是给插件起个 ID，真正生效得靠micro.WithLogger(myLogInstance)显式传入实现了logger.Logger接口的实例 - Broker、Transport、Codec 这些都不再从环境变量（如
MICRO_BROKER=nats）自动读取，v4 只认MICRO_REGISTRY这类基础项，其余都得自己桥接 - 在
service.Init()之后才 new 一个nats.NewBroker()并试图赋值给 server options，完全无效——options 是只读快照，改了不生效
替代方案选 kitex 还是手写 gRPC + etcd
kitex 不是“另一个框架”，它是字节生产级 RPC 框架，开箱支持熔断、限流、泛化调用，且持续适配 Go 新版本；而 gRPC 是协议标准，不是框架，你得自己拼注册发现、负载均衡、中间件。
- kitex 吞吐比手写 gRPC 中间件高 15%~20%，赢在连接复用策略和内存对象池优化
- kitex 启动连不上 Nacos？大概率是鉴权或路径问题：
nacos.NewDefaultNacosConfig()不带账号密码，默认被 403 拦截；地址必须显式写成http://127.0.0.1:8848/nacos（含/nacos前缀）；服务名不能含下划线 - 真正麻烦的从来不是“怎么让两个服务通上”，而是“通上之后，当 Nacos 重启、网络抖动、服务实例闪退时，你的重试逻辑有没有覆盖所有超时分支”——
client.WithRPCTimeout和client.WithConnectTimeout必须分开设，很多人只设一个
go-micro 的插件化理念本身没错，但它的实现已脱离当前 Go 生态演进节奏。现在花时间调通 v4，不如用 kitex 写完服务再顺手加个熔断器——后者是现成的，前者是自己造轮子还带 bug。
