Go中unsafe编码指针传参问题：为何触发GC相关致命错误？

问题背景 #

在小端序系统中，存在两种仅参数传递方式不同的Go编码函数：

方案1：接收指针参数 #

func Encode(v *float32) []byte {
    return unsafe.Slice((*byte)(unsafe.Pointer(v)), 4)
}

方案2：接收值参数 #

func Encode(v float32) []byte {
    return unsafe.Slice((*byte)(unsafe.Pointer(&v)), 4)
}

当前遇到偶现的GC相关致命错误，仅在GC触发时出现：

• fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
• found pointer to free object | bad use of unsafe.Pointer?

经排查怀疑根因为方案1的使用，以下是具体分析：

方案1的核心问题 #

方案1存在的本质风险是返回的切片与原指针指向的内存直接共享底层空间：

• 当传入的指针指向的对象（如float32、Uuid）没有被其他存活引用持有时，Go GC会判定这块内存可回收
• 一旦GC触发回收，后续访问返回的[]byte时，会直接访问已释放的内存，触发“found pointer to free object”或段错误
• 尤其危险的场景是传入临时对象的指针（如Encode(&float32(1.23))），临时对象生命周期极短，GC极易在后续操作前回收其内存

方案2的安全性优势 #

方案2通过值传递参数，规避了上述风险：

• 函数内的v是原变量的栈上副本（若未触发逃逸），返回的切片引用该副本的内存
• 若返回的切片被立即使用（如写入IO、拷贝到其他缓冲区），栈内存尚未被覆盖，不会触发错误
• 若切片需要长期持有，Go的逃逸分析会自动将v分配到堆上，GC会跟踪切片对堆内存的引用，不会提前回收

扩展类型的处理建议 #

对于Uuid这类数组类型，无需使用unsafe包，直接返回数组切片即可，更安全且简洁：

type Uuid [16]byte

// 推荐写法：直接返回数组切片，无需unsafe
func EncodeUuid(v Uuid) []byte {
    return v[:]
}

若必须使用unsafe处理其他非数组类型，优先采用值传递的方案2模式。

调试与验证建议 #

• 继续使用激进GC参数复现问题：

  GODEBUG=invalidptr=1,cgocheck=1,madvdontneed=1 GOGC=2 GOMEMLIMIT=10MiB ./my-executable
  

• 启用-d=checkptr编译参数，让Go编译器在编译阶段检查unsafe.Pointer的不安全使用，提前发现问题
• 排查所有调用Encode类函数的代码，避免传入临时对象的指针，确保原对象在返回切片的生命周期内始终被有效引用

内容的提问来源于stack exchange，提问作者Arjun Sunil Kumar