Go的GC根对象扫描是分类型、分阶段、带STW控制的多步任务调度过程，包含Data、BSS、Stack、Span和Fixed五类根来源，其中栈扫描最易漏标，需STW保障精度，且CGO边界和栈map错误常致崩溃。
Go 的 GC 根对象扫描不是一次性遍历所有全局变量和栈，而是分类型、分阶段、带 STW 控制的多步任务调度过程。
根对象包含哪些具体来源
GC 启动后标记阶段的第一批“起点”对象统称根对象（Root Objects），它们不通过其他 Go 对象可达，而是由运行时环境直接持有引用。主要包括：
-
Data Roots：可读写段（.data）中的全局变量，如已初始化的包级var变量 -
BSS Roots：只读段（.bss）中的零值全局变量，如未显式初始化的var x int -
Stack Roots：每个活跃G的栈帧上可能含指针的局部变量（需栈展开解析） -
Span Roots：mspan中嵌入的终结器（finalizer）链表等特殊结构 -
Fixed Roots：固定位置对象，如finalizer队列、已中止G的待释放栈、mcache中待 flush 的 span 等
注意：tiny allocator 分配的小对象（< 16B）不参与根扫描，因为其内存块本身无独立指针位图，归属其所属的更大 span 统一处理。
扫描如何触发与分阶段执行
根扫描不是在 GC 开始瞬间全量完成，而是按阶段拆解、部分要求 STW、部分并发执行：
-
gcMarkRootPrepare先计算各类型根任务数量（例如有多少个 G 的栈需要扫描），并预分配标记队列空间 -
markroot函数被多个后台 mark worker goroutine 并发调用，但每次只处理一个子任务（如“第 7 个 G 的栈”或“第 3 个 mspan 的 finalizer 列表”） -
Data Roots和BSS Roots扫描在第一次 STW（STW mark termination前）完成，确保全局变量状态一致 -
Stack Roots扫描在 GC 初始 STW 阶段完成——此时所有G被暂停并安全栈展开；但若发现某G正在系统调用中，会延迟到该G返回用户态时再扫描 -
Flush Cache Roots（清空mcache）必须在 STW 下执行，否则 span 可能被并发修改
这意味着：你看到的 “GC STW 时间长”，往往不是因为标记逻辑慢，而是卡在等待所有 G 安全停靠、或等待 mcache 刷出的同步点上。
为什么栈扫描容易出错或漏标
栈是根对象里最动态、最难精确解析的部分，常见问题集中在：
- 编译器生成的栈对象布局信息（
stack map）必须与实际运行时栈帧严格匹配；若内联、逃逸分析变更导致栈 map 错误，就会漏标存活对象 → 直接引发悬空指针 - goroutine 处于
Gsyscall或Gwaiting状态时，栈可能不可访问，GC 会跳过并标记为“待后续扫描”，但如果该G永远不恢复，其栈上对象就可能被误回收 - 写屏障仅对堆对象生效；栈上新写入的指针不会触发屏障，所以 GC 必须在 STW 下完成栈扫描，否则并发写入会导致漏标
- CGO 调用中 C 栈上的 Go 指针无法被 Go 运行时识别，必须用
//go:cgo_export_static或手动管理，否则必漏标
这也是为什么 runtime: found pointer to unallocated memory 或 unexpected fault address 类 panic，90% 都源于栈扫描遗漏或 CGO 边界失控。
如何观察当前根扫描行为
调试时可通过以下方式确认根扫描是否正常工作：
- 启动时加
GODEBUG=gctrace=1，输出中scanned行末尾的数字即本次扫描的根对象数（如scanned 12480） - 用
go tool trace查看GC/STW/MarkRoots子事件耗时，对比Mark总时间和各阶段占比 - 检查
runtime.ReadMemStats中的NextGC和HeapAlloc关系，若频繁 GC 但HeapAlloc不涨，可能是根扫描漏掉大对象，导致 GC 认为内存紧张而误触发
真正难调的 GC 问题，往往不在堆对象本身，而在根集合是否完整——尤其是跨 CGO、信号 handler、或深度内联后的栈 map 是否仍准确。这点极易被忽略，但一旦出错就是崩溃级问题。
