go-micro v4 必须显式传入 registry、transport、broker 等核心组件，否则服务静默失败；micro.newservice() 阶段未注入则 service.init() 无法补救，且插件名仅作标识，不触发自动装配。
Go-Micro v4 不再自动加载插件，micro.NewService() 必须显式传入 registry、transport、broker 等核心组件，否则服务启动后“看似正常”但实际无法注册、无法通信、错误静默——这是绝大多数人卡住的第一步。
micro.NewService() 为什么连不上 Consul/etcd？
v4 彻底移除了隐式插件机制。以前写 micro.NewService(micro.Registry()) 就能用，默认走 mDNS；现在这行代码直接编译失败或运行时 no registry configured 而不 panic。
- 必须显式构造注册中心实例，例如：
etcd.NewRegistry()或consul.NewRegistry()，且需提前go get github.com/micro/go-micro/v4/registry/etcd - 传入方式不是字符串或配置结构体，而是
micro.WithRegistry(reg)这样的选项函数 -
service.Init()不会补救——它只解析环境变量和命令行参数，不初始化插件；registry/broker/transport 必须在NewService()阶段就注入 - 别用
MICRO_REGISTRY=consul期望框架自动识别：v4 只读MICRO_REGISTRY基础项，MICRO_BROKER等全被忽略，必须手动桥接
如何让 RPC 服务真正跑起来（不只是编译通过）？
定义 handler 后调用 service.Run()，但客户端发请求 404 或 timeout，常见原因不是逻辑错，而是 transport 和 codec 没配对。
- transport 决定底层通信协议，默认是
http，但若你用了grpc编码器却没换 transport，就会 mismatch - codec 控制序列化格式，
protobuf需搭配proto.Marshal兼容的实现；json编码器不能解析二进制 protobuf payload - RPC 方法名必须与
.proto中定义的 service 名 + rpc 名完全一致（大小写敏感），比如Greeter.Hello，否则MICRO_ENDPOINTheader 匹配失败 - 测试时 curl 要带两个 header：
-H 'Content-Type: application/json'和-H 'Micro-Endpoint: Greeter.Hello'，缺一不可
Broker（消息总线）怎么启用又不踩坑？
想用 NATS 或 Kafka 做事件驱动，但 service.Server().Options().Broker 始终是 nil，不是没装包，而是根本没注入。
-
micro.WithBroker()必须作为选项传给micro.NewService()，例如：micro.WithBroker(nats.NewBroker()) - 别在
Init()之后 new 一个 broker 再试图赋值——Server().Options()返回的是只读快照，改了无效 - NATS 默认监听
localhost:4222，确保本地已运行nats-server，否则 broker 连接失败但日志可能只打印一句 warning - 发布消息用
service.Client().Publish()，订阅用service.Server().Subscribe()，二者必须使用同一 broker 实例，跨 service 也要复用同一个 broker 对象
最易被忽略的点：v4 的插件名（如 "nats"）只是标识符，不触发自动装配；plugin.Get("nats") 能取到实例，但框架本身完全不关心这个名——所有依赖都靠显式传参绑定，没有 magic string fallback。
