grpc resolver 必须实现 resolver.builder（含 build 方法）和 resolver.resolver（含 resolvenow、close 方法），且 build 必须返回非 nil 实例并触发首次解析，resolvenow 需主动刷新地址，close 需清理 goroutine 和 channel。
gRPC Resolver 接口必须实现哪些方法才能被识别
gRPC 的 Resolver 不是插件式注册，而是通过 resolver.Register 显式注册后，由 scheme（如 mydns://）触发调用。核心在于实现 resolver.Builder 和 resolver.Resolver 两个接口。
常见错误是只写解析逻辑但没导出 Build() 方法，或返回的 Resolver 没实现 ResolveNow() 和 Close() —— 这会导致 gRPC 启动时静默失败，日志里只报 resolver returned nil 或直接 panic。
-
Build()必须返回非 nil 的resolver.Resolver实例，且内部需能触发首次解析（比如启动 goroutine 调用watch()） -
ResolveNow()不能空实现：它用于主动刷新地址，若不做任何事，服务实例上下线就无法感知 -
Close()必须清理后台 watch goroutine 和 channel，否则连接池会持续引用已下线节点
如何让 gRPC 客户端使用自定义 Resolver 而不改 Dial 参数
关键不是改 grpc.Dial()，而是提前注册 + 统一使用对应 scheme。比如注册了 myresolver，就必须用 myresolver:///service-name 作为 target，不能混用 dns:/// 或裸 IP。
容易踩的坑是：本地开发时用 localhost:8080 测试，上线却忘了切回自定义 scheme，结果 resolver 根本没加载，客户端直连失败还查不出原因。
- 注册必须在
main()开头或 init() 中完成：resolver.Register(&myBuilder{}) - target 字符串必须以注册的 scheme 开头，且带三个斜杠：
myresolver:///user-service（注意不是两个） - 如果要用环境变量或配置中心控制 scheme，务必确保所有服务间 scheme 一致，否则部分 client 会 fallback 到默认 resolver
动态连接池管理：为什么不能在 Resolver 里直接 new ClientConn
Resolver 只负责提供地址列表（resolver.Address），不负责建连。gRPC 内部会基于这些地址按需创建和复用 *grpc.ClientConn。如果你在 Resolver 里手动 dial，不仅绕过负载均衡策略，还会导致连接泄漏和健康检测失效。
典型症状是：服务扩缩容后，客户端仍往已下线节点发请求，错误日志出现大量 connection refused 或 transport is closing，但 Resolver.ResolveNow() 其实已经更新了地址。
- 真正该做的是在
UpdateState()回调中，把新地址列表交给 gRPC 内部处理：cc.UpdateState(resolver.State{Addresses: addrs}) - 连接池行为由
grpc.WithTransportCredentials()、grpc.WithBlock()等 Dial 选项控制，和 Resolver 无关 - 若需细粒度控制连接生命周期（比如按 region 分流），应在 Balancer 里实现，而不是在 Resolver 里 hold conn
Resolver 返回地址时，哪些字段影响负载均衡和重试
resolver.Address 不只是 IP+Port。gRPC 会读取其中的 ServerName、Attributes 和 Metadata 字段，决定是否启用 TLS、走哪个 Balancer、甚至是否跳过健康检查。
最常被忽略的是 Attributes：它是任意键值对，Balancer 可从中提取权重、区域标签、版本号等信息。没设这个，再复杂的路由策略也白搭。
-
Address.ServerName会被用于 TLS SNI，若为空且启用了 TLS，握手会失败 -
Address.Attributes必须用balancer.NewPickerBuilder().Build()可识别的结构传入，推荐用attributes.New("region", "shanghai") -
Address.Metadata是透传给底层 transport 的，一般不用；误塞大对象会导致内存占用异常升高
复杂点在于：Resolver 和 Balancer 必须协同工作。Resolver 提供带标签的地址，Balancer 才能做加权轮询或 locality-aware 路由——单边实现没意义。
