Stack walking 是 GC 在标记阶段扫描 goroutine 栈以识别存活指针的过程；它依赖编译器生成的 funcinfo 和 pcdata 元数据，逐帧解析栈内容，精准判定哪些值是指针并加入标记队列，确保逃逸分析未覆盖的引用（如栈变量地址写入堆、接口/切片 header 等）不被误回收。
stack walking 是什么，为什么 GC 需要它
go 的 gc 必须知道哪些变量还“活着”，而根对象（roots）里最关键的一类就是当前所有 goroutine 的栈上变量。stack walking 就是 gc 在标记阶段扫描每个 goroutine 栈的过程——逐帧解析栈内存布局，识别出其中哪些字是潜在的指针（即可能指向堆对象），并把它们加入标记队列。runtime.scanobject 和 scanframe 这类函数背后依赖的就是这套机制。它不是靠编译器插桩或运行时记录引用链，而是直接读栈内容、结合编译器生成的栈对象元信息（stack object metadata）做语义还原。
栈帧元信息从哪来：funcinfo 和 pcdata
Go 编译器在生成函数代码时，会为每个函数附带两段关键元数据：funcinfo（描述函数栈帧结构）和 pcdata（按 PC 偏移给出栈上各位置是否为指针、是否需被扫描）。GC 执行 stack walking 时，拿到某个 goroutine 的当前 PC 和 SP，就能查表定位到正在执行的函数，再用 pcdata 精确判断：从 SP 开始往上偏移 8 字节那个值是不是指针？偏移 24 字节那个值是不是指向堆对象的接口？这些信息决定了要不要把那个地址当作根对象加入灰色队列。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 有时就源于栈上某处本该是有效指针却被误判为非指针（或反之），导致 GC 清除了还在用的对象，后续解引用就崩了。
为什么不能只靠逃逸分析跳过栈扫描
逃逸分析能告诉编译器“这个变量会不会逃逸到堆”，但它无法替代 stack walking——因为：
- 栈上变量可能被写入堆对象字段（如
heapObj.ptr = &localVar），此时 localVar 虽未逃逸，但它的地址已暴露给堆，必须保活； - 接口类型、切片、map 等复合类型在栈上只存 header，真实数据在堆，header 里的指针字段必须被扫描；
- CGO 调用中栈布局不可控，
pcdata会保守标记更多区域，避免漏标。
也就是说，逃逸分析解决的是“分配在哪”，stack walking 解决的是“谁还在引用”。二者分工明确，缺一不可。
实际影响：STW 与并发标记的边界在哪里
stack walking 发生在 GC 的两个 STW 阶段：初始标记（markroot）和标记终止（marktermination）。前者扫描所有 goroutine 的栈快照，后者确保没有新栈帧在标记过程中“漏网”。虽然 Go 1.5+ 后大部分标记工作并发进行，但栈扫描本身必须 STW——因为 goroutine 正在跑，栈指针（SP）随时变化，不暂停就无法获得一致快照。
容易踩的坑：goroutine 栈过大（比如递归过深或局部数组超大）会导致单次 stack walking 耗时飙升，直接拉长 STW 时间；大量短生命周期 goroutine 则让 GC 频繁扫描新栈，增加 CPU 开销。这时观察 gctrace=1 输出里的 scanned 字段和 STW 时长，比调优 GC 参数更有效。
真正难的不是“怎么扫”，而是“扫得准不准”——这取决于编译器生成的 pcdata 是否完整、runtime 对栈帧边界的判定是否鲁棒。一旦元数据错位或栈被破坏（如 CGO 中手动改 SP），GC 就可能漏标或误标，后果是悬挂指针或内存泄漏。这类问题往往复现困难，且不报错，只在压力下偶发崩溃。
