无需反射在Go泛型函数中获取类型大小的可行方案

完全可以不借助反射实现泛型类型的字节序列化，而且有多种比反射更高效、更可靠的方案，以下是具体实现：

方案一：利用unsafe.Sizeof获取编译期确定的类型大小 #

unsafe.Sizeof在泛型函数中会针对每个实例化的类型（如Item[uint16]、Item[uint32]）在编译期计算出类型大小，完全没有运行时开销，性能远优于反射。

package main

import (
	"encoding/binary"
	"fmt"
	"unsafe"
)

type KeyType interface {
	uint16 | uint32 | uint64
}

type Item[KT KeyType] struct {
	Key  KT
	Data []byte
}

func MarshalBinary[KT KeyType](i *Item[KT]) ([]byte, error) {
	keySize := int(unsafe.Sizeof(i.Key))
	totalSize := keySize + len(i.Data)
	buf := make([]byte, totalSize)

	// 根据预计算的大小写入Key
	switch keySize {
	case 2:
		binary.BigEndian.PutUint16(buf, uint16(i.Key))
	case 4:
		binary.BigEndian.PutUint32(buf, uint32(i.Key))
	case 8:
		binary.BigEndian.PutUint64(buf, uint64(i.Key))
	}

	// 写入Data部分
	copy(buf[keySize:], i.Data)
	return buf, nil
}

func main() {
	i := &Item[uint32]{Key: 42, Data: []byte("test data")}
	data, err := MarshalBinary(i)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Printf("Serialized: %x\n", data)
}

方案二：泛型类型分支（安全无unsafe依赖） #

通过Go 1.18+支持的泛型类型断言分支，直接对KT类型进行判断，代码更清晰，且完全不需要依赖unsafe包，同样是编译期确定分支逻辑，无运行时性能损耗。

package main

import (
	"encoding/binary"
	"fmt"
)

type KeyType interface {
	uint16 | uint32 | uint64
}

type Item[KT KeyType] struct {
	Key  KT
	Data []byte
}

func MarshalBinary[KT KeyType](i *Item[KT]) ([]byte, error) {
	var keyBuf []byte
	// 利用类型断言分支匹配具体类型
	switch k := any(i.Key).(type) {
	case uint16:
		keyBuf = make([]byte, 2)
		binary.BigEndian.PutUint16(keyBuf, k)
	case uint32:
		keyBuf = make([]byte, 4)
		binary.BigEndian.PutUint32(keyBuf, k)
	case uint64:
		keyBuf = make([]byte, 8)
		binary.BigEndian.PutUint64(keyBuf, k)
	default:
		// 由于KeyType约束了类型范围，此分支不会触发
		return nil, fmt.Errorf("unsupported key type")
	}

	// 拼接Key和Data的字节数据
	return append(keyBuf, i.Data...), nil
}

func main() {
	i := &Item[uint64]{Key: 123456, Data: []byte("hello")}
	data, err := MarshalBinary(i)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Printf("Serialized: %x\n", data)
}

为什么不推荐反射方案？ #

你提供的反射方案存在两个严重问题：

1. 性能损耗：反射的类型解析是运行时操作，会带来明显的性能开销，尤其在高频序列化场景下影响显著。
2. 可靠性差：通过strings.Contains(t.String(), "uint32")判断类型的方式非常脆弱，如果使用类型别名（如type MyUint32 uint32），字符串判断会失效，导致逻辑错误。

方案选择建议 #

• 优先选择方案二：代码更易读、安全，无unsafe依赖，性能与方案一几乎无差异。
• 如果追求极致性能，且确定不会涉及类型别名等场景，可以选择方案一。

内容的提问来源于stack exchange，提问作者jrefior