earthchen
使用reflection拿到的全路径是 java_package ,而 grpc 标准的全路径是 package,这是合理的
贴一下 Idl 把 ，然后再说明一下用的是 stub 还是 reflection模式，方便的话提个 demo 的链接上来看看
> 猜测，问题的关键在于，对于protobuf，生产者与消费者的进程间桥梁是package，各自进程stub的xxx_package与package相互衔接。如果是golang调用java项目，需要历经go_package -> package -> package -> java_package。而dubbo注册到nacos上的不是package，而是java_package，就使得这个桥梁没有接上。 对于 pb 来说, 实际的请求path 是 package，在java 测 stub模式下所支持的 path 也是 package，虽然包路径是 java_package，go 侧同理，但是对于服务发现来说，这个可能得考虑一下到底注册 java_package 还是 package
> > > > 是的，对于3.1.x来说是这样的。而3.2.x，使用grpcurl 127.0.0.1的方式也不行，说明这个版本从package -> java_package这个桥梁也没有接上。 3.2x 默认关闭了内置服务，需要按需打开内置的反射服务，grpcurl 需要通过反射拿到 metadata 才可以访问
Because the header of HTTP2 does not support non-ASCII code.
@xiaoyuuuuuupeng
protostuff 只是一种序列化而已，tri 本身并不绑定序列化
麻烦你开启 debug 日志，然后重新复现一下 然后把中间那次失败日志提供一下
能更具体的说明一下吗?