Dubbo-go 启动后注册不到 Nacos 主因是协议不匹配：Java Dubbo 默认用 dubbo 协议，而 dubbo-go 0.9+ 默认用 tri 协议，需显式配置 protocol: dubbo 或升级至 v1.5.x 兼容版本。
为什么 dubbo-go 启动后注册不到 Nacos？
不是配置写错了，大概率是服务发现协议没对齐。Java 的 Dubbo 默认用 dubbo 协议注册，而 dubbo-go 0.9+ 默认走 tri（Triple）协议，Nacos 控制台看到的服务名可能带 tri:// 前缀，Java 消费端根本认不出来。
- 检查
registry配置里是否显式指定了protocol: dubbo，而不是留空或写成tri - 确认
dubbo-go版本：v1.5.x 开始才默认兼容 Java 的dubbo协议注册格式；旧版本必须手动设serviceConfig.Protocol = "dubbo" - Nacos 中查服务时，别只看
providers列表，要进详情页看metadata字段——如果出现"protocol":"tri"，说明协议不匹配 - Java 端
dubbo-registry-nacos版本低于 3.2.0 时，对tri元数据解析会失败，降级用dubbo协议最稳
consumer.GetRPCService() 返回 nil 怎么办？
这是初始化顺序踩坑的典型表现：dubbo-go 的服务引用不是声明即可用，必须等 config.Load() 完成、且 registry 连接就绪后，才能拿到有效句柄。直接在 init() 或变量定义阶段调用，必然返回 nil。
- 所有
GetRPCService()调用必须放在config.Load()之后，推荐塞进main()函数靠后位置 - 别信文档里“全局变量 + init”那种写法，
dubbo-go的 lazy-init 机制会让它在第一次调用前才真正初始化连接，但GetRPCService()不触发这个流程 - 加个简单检查：
if svc == nil { panic("service not ready, config.Load() may not be called") } - 如果用了 Go 的
sync.Once包装初始化逻辑，注意Once.Do()里不能包含阻塞 registry 探测的操作，否则可能死锁
Java 提供的 GenericService 能被 dubbo-go 直接调用吗？
不能直连。Java 的泛化调用依赖 GenericFilter 和特定的序列化头（如 Hessian2），而 dubbo-go 默认走 JSON 或 Protobuf 序列化，两边编解码层完全不通。
- 真要泛化调用，得在 Java 端暴露一个标准
String invoke(String method, String jsonArgs)接口，用 JSON 统一收发，绕过 Dubbo 自带泛化机制 -
dubbo-go的generic模块（hessian.NewGenericClient()）仅支持 Hessian2，且要求 Java 端开启generic=true并配好对应 filter，实测成功率低、调试成本高 - 更现实的做法：Java 端提供一组明确的 RPC 接口（哪怕只是透传 JSON 字符串），
dubbo-go用强类型 client 调用，语义清晰、链路可观测
超时设置为什么在 consumer 配置里不生效？
因为 dubbo-go 的超时是分层控制的：consumer 配置只管「发起请求前」的等待（比如找 provider 实例），真正的网络调用超时由 referenceConfig 的 Timeout 字段决定，而且它单位是毫秒，不是秒。
立即学习“Java免费学习笔记（深入）”；
- 检查代码里是不是只改了
consumer.Timeout，却漏掉referenceConfig.Timeout = 3000这一行 - 如果用了 YAML 配置，确保层级对齐：
reference:下的timeout是独立字段，不在consumer:下面 - HTTP/2 场景下（
tri协议），还受keepalive和stream级超时影响，建议统一用referenceConfig.Timeout控制主超时 - 日志里搜
"timeout="能看到实际生效值，比猜配置靠谱
协议对齐、初始化时机、序列化边界、超时作用域——这四个点卡住 80% 的跨语言联调。细节都在配置和调用顺序里，不在文档第一行。
