Go GC是否会递归追踪unsafe.Pointers？

核心问题：GC不知道你自定义内存块的边界和布局 #

Go的精确GC依赖类型元数据工作——它只认识Go语言原生语法定义的类型（struct、array、slice、map等），这些类型的内存布局、字段类型、整体大小都在编译期就被记录在元数据里。

如果你是手动分配一片连续内存（比如用syscall.Mmap或unsafe从某个内存块里切出来），然后自己在里面填充unsafe.Pointer和普通值，GC完全不知道这片内存的结构：

• 它只会把你持有的那个指向起始位置的unsafe.Pointer当作一个单独的根引用，确保这个指针指向的内存不被回收，但不会扫描这片内存后面的内容。
• 对于你例子里的[A, b, c, D, e, F]，GC只知道A是一个unsafe.Pointer（因为你持有它），但不知道A后面还有b、c、D这些数据，更不会把D、F当作需要追踪的指针。这就导致D、F指向的内存可能被GC标记为可回收，后续被新分配的内存覆盖，从而出现变量值随机变更的问题。

为什么关闭GC问题就消失？ #

关闭GC后，Go停止了内存回收和复用流程，所有分配过的内存都不会被释放，哪怕没有引用指向它们。所以D、F指向的内存不会被覆盖，自然不会出现值异常——但这只是临时规避，不是解决方案。

正确的解决思路 #

要让GC正确追踪你的自定义数据结构，必须让它能识别内存布局：

• 优先用Go原生类型定义结构：把你的自定义布局写成一个struct，明确声明哪些字段是unsafe.Pointer，哪些是普通值。这样编译期会生成对应的类型元数据，GC能准确知道结构的边界，以及哪些位置需要扫描指针。

  type CustomStruct struct {
      A unsafe.Pointer
      b uint64
      c uint64
      D unsafe.Pointer
      e uint64
      F unsafe.Pointer
  }
  

  这种情况下，只要你持有一个*CustomStruct或者指向它的unsafe.Pointer，GC就会扫描整个struct的所有字段，追踪A、D、F这些指针。
• 如果必须手动管理内存块：确保所有内部的unsafe.Pointer都被GC可见的根引用直接持有（比如存在全局变量、局部变量、原生容器里），或者在使用完这些指针后调用runtime.KeepAlive来延长它们的生命周期。但这种方式极易出错，不推荐在非极端场景使用。
• 避免在无类型元数据的内存里存储指针：任何存放在“裸”内存块里的unsafe.Pointer，GC都不会当作指针处理，只会把它当成普通的整数，自然不会追踪其指向的内存。

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