Go Micro v4 中 micro.NewService 不再自动加载插件，必须显式传入 registry、transport、broker、codec 等选项，否则服务无法连接注册中心或发送请求，且错误静默不报。
Go Micro v4 里 micro.NewService 不再自动加载插件？
对，v4 彻底移除了隐式插件注册机制。以前靠 micro.DefaultOptions() 自动塞进 registry、transport 等，现在必须显式传入——否则服务启动后根本连不上注册中心，日志里也只有一句 no registry configured，不报错但就是不工作。
- 必须手动调用
micro.WithRegistry()、micro.WithTransport()等选项函数，哪怕用默认实现也要写出来 - v4 的
registry默认不包含etcd或consul实现，得单独go get github.com/micro/go-micro/v4/registry/etcd，再用etcd.NewRegistry()构造 - 别直接复用 v3 的
micro.NewService(micro.Registry(...))写法——v4 的选项函数签名变了，参数是registry.Registry接口，不是字符串或配置结构体
为什么 service.Init() 调用后 service.Server().Options().Broker 还是 nil？
因为 Init() 只解析命令行和环境变量，并不触发插件初始化；Broker、Registry、Transport 这些核心组件，得在 micro.NewService() 阶段就通过选项注入，而不是靠后续 Init 补救。
- Broker 必须用
micro.WithBroker(broker)显式传入，比如micro.WithBroker(nats.NewBroker()) - 如果依赖环境变量（如
MICRO_BROKER=nats），v4 不再自动识别——它只读MICRO_REGISTRY这类基础项，Broker/Transport/Codec 都要自己桥接 - 常见陷阱：在
Init()之后才 new 一个nats.NewBroker()并试图赋值给 server options，但 options 是只读快照，改了没用
自定义插件时，plugin.WithName("mylogger") 注册后为啥日志还是没走你的逻辑？
Go Micro v4 的插件系统只负责“发现”，不负责“激活”；注册名字只是标识，真正生效得看服务是否在构造时明确选择了它。
- Logger 插件必须配合
micro.WithLogger()使用，且传入的是实现了logger.Logger接口的实例，不是插件名 - 插件名（如
"mylogger"）只在你调用plugin.Get("mylogger")手动取实例时有用，框架本身不按名自动装配 - 想让所有 service 共享一套 logger，别依赖插件注册表，直接 new 一个实例，全局复用并传给每个
micro.NewService(micro.WithLogger(myLog))
micro.Service 的 Client() 和 Server() 方法返回对象，能直接拿来发请求吗？
不能。它们返回的是内部封装过的 client/server 实例，但默认不带编码器、不带中间件、也不绑定 broker——直接调用 client.Call() 会 panic 报 codec not found 或 no transport configured。
- 发起 RPC 请求必须用
service.Client().Call()，且该 service 必须已通过micro.WithCodec()指定了编解码器（如json.NewCodec()） - 如果是发异步事件，
service.Client().Publish()前，service 得先配好micro.WithBroker()，否则 publish 无声失败 - 别试图从
service.Server()提取 transport 来手动 dial——transport 是 server 内部监听用的，client 侧走的是另一套连接池逻辑
插件化不是“注册即生效”，v4 把控制权全交还给使用者：每个组件都得亲手接线，少一步，运行时就断在看不见的地方。最常漏的是 WithCodec 和 WithBroker，因为错误不抛异常，只静默降级。
