Go泛型类型参数约束疑问：protobuf实体序列化报错如何解决

我正在用Go泛型做一个操作Protobuf消息的自定义数据库驱动，需要约束泛型的指针类型，让编译器知道它实现了特定方法。

最开始我这么定义实体约束：

type Entity interface {
   pb.MsgA | pb.MsgB | pb.MsgC
}

对应的泛型DB接口：

type DB[E Entity] interface {
   Get(...) (E, error)
   List(...) ([]E, error)
   // 其他方法
}

但写序列化函数的时候报错了：

func Encode[E Entity](v *E) ([]byte, error) {
   return proto.Marshal(v)
}

错误提示：

cannot use val (variable of type *E) as type protoreflect.ProtoMessage in argument to proto.Marshal: *E does not implement protoreflect.ProtoMessage (type *E is pointer to type parameter, not type parameter)

问题出在proto.Marshal要求参数实现proto.Message接口，但当前的Entity约束只包含值类型，编译器没法推断*E满足这个接口。

我试过改成这样：

type Entity interface {
   *pb.MsgA | *pb.MsgB | *pb.MsgC
   proto.Message
}

但这种方式需要额外的protoreflect操作来实例化对象，感觉不太顺手。

方案一：直接把Entity约束成指针类型，优化实例化逻辑 #

其实Protobuf生成的代码里，只有消息类型的指针才会实现proto.Message接口，所以直接把Entity约束成指针类型才是贴合设计的选择。实例化对象的时候，可以用Protobuf自带的反射机制，不用额外复杂操作：

import (
   "google.golang.org/protobuf/proto"
   "google.golang.org/protobuf/reflect/protoreflect"
)

// 约束为指针类型且实现proto.Message
type Entity interface {
   *pb.MsgA | *pb.MsgB | *pb.MsgC
   proto.Message
}

// 生成新的实体实例
func NewEntity[E Entity]() E {
   var zero E
   // 通过ProtoReflect获取消息类型，创建新实例
   msgType := zero.ProtoReflect().Type()
   newMsg := msgType.New().Interface()
   return newMsg.(E)
}

// 现在Encode可以直接正常运行
func Encode[E Entity](v E) ([]byte, error) {
   return proto.Marshal(v)
}

// 对应的DB接口也改成返回指针类型
type DB[E Entity] interface {
   Get(...) (E, error)
   List(...) ([]E, error)
   // 其他方法
}

这个方案完全符合类型安全，实例化逻辑也很简洁，后续的克隆、合并操作也能基于proto.Message接口顺利实现。

方案二：保持Entity为值类型，给泛型函数加额外约束 #

如果一定要保留值类型的Entity约束，可以在Encode函数里明确告诉编译器*E实现了proto.Message：

type Entity interface {
   pb.MsgA | pb.MsgB | pb.MsgC
}

// Go 1.18+支持的语法，直接约束*E实现proto.Message
func Encode[E Entity](v *E) ([]byte, error) where *E: proto.Message {
   return proto.Marshal(v)
}

不过这种方式有个缺点：后续只要涉及指针类型的操作（比如克隆、反序列化），都得重复加这个约束，代码会变得啰嗦。

总结 #

优先选方案一，因为Protobuf的核心操作（序列化、反序列化）本来就依赖指针类型，把Entity约束成指针类型更符合它的设计逻辑，后续开发也会更顺畅。

内容的提问来源于stack exchange，提问作者Michael B.