runtime.Stack常返回空或截断堆栈，因其默认仅捕获当前goroutine且缓冲区仅4KB；需传足够大buf（如64KB）并设第二参数为true才获取全部goroutine完整堆栈。
runtime.Stack 为什么经常返回空或截断的堆栈？
因为 runtime.Stack 默认只捕获当前 goroutine 的堆栈，且默认缓冲区大小仅 4KB —— 多数嵌套调用稍深就会被截断。如果你在主 goroutine 或一个刚启动的轻量 goroutine 中调用它，很可能只看到几行 runtime 初始化代码，甚至返回 0 字节。
实操建议：
- 传入
buf必须足够大（例如make([]byte, 64*1024)），否则返回值是实际写入长度，小于 buf 长度即表示被截断 - 第二个参数设为
true才会打印所有 goroutine 堆栈；设为false只抓当前 goroutine - 别在 defer 中无条件调用它 —— 若 panic 已发生，部分 goroutine 可能已退出，堆栈不可靠
如何安全获取所有 goroutine 的完整堆栈用于诊断死锁？
死锁场景下，runtime.Gosched() 不起作用，但 runtime.Stack 仍可工作 —— 关键是避免依赖运行时调度器状态。最稳妥的方式是提前预留大 buffer，并在信号 handler 或独立 goroutine 中触发。
示例片段（非阻塞式采集）：
buf := make([]byte, 2*1024*1024) // 2MB 足够覆盖数千 goroutine
n := runtime.Stack(buf, true)
if n == len(buf) {
// 仍可能截断，但概率极低；可 warn 或 fallback 到更小粒度采样
}
log.Printf("dumped %d bytes of goroutine stacks", n)
注意：runtime.Stack 是同步操作，若在高并发关键路径频繁调用，会导致显著停顿（尤其 all=true 时需遍历全部 goroutine 结构体）。生产环境建议仅在 SIGQUIT、pprof /debug/pprof/goroutine?debug=2 等受控入口使用。
与 pprof 的 goroutine profile 对比：该选哪个？
runtime.Stack 返回的是即时、带源码行号的文本堆栈（类似 panic 输出），而 pprof.Lookup("goroutine").WriteTo 输出的是采样摘要（默认只含正在运行/阻塞的 goroutine，且无文件名和行号）。
选择依据：
- 查「此刻谁卡在 select/channel 上」→ 用
runtime.Stack(buf, true)，看完整阻塞点 - 查「长期存在但不该存在的 goroutine 泄漏」→ 用
pprof.Lookup("goroutine").WriteTo+ diff 多次快照 - 想集成到 HTTP 接口暴露堆栈 → 直接复用
/debug/pprof/goroutine?debug=2，它底层就调了runtime.Stack，且已处理好 buffer 和 charset
跨 goroutine 获取指定 goroutine 的堆栈可行吗？
不可行。runtime.Stack 没有接收 goroutine ID 或指针的参数，Go 运行时也不导出 goroutine 句柄。所谓「指定 goroutine」只能靠间接方式实现：
- 在目标 goroutine 内部主动调用
runtime.Stack并发给 channel 或写日志 - 用
debug.SetTraceback("system")提升 panic 时的堆栈深度，再触发 panic（仅限调试） - 借助第三方工具如
delve的goroutines -t命令，在进程外 attach 后按 ID 查看
别尝试用 unsafe 或反射去读 runtime.g 结构 —— 字段布局不保证稳定，Go 1.22 已重构 goroutine 状态机，这类 hack 极易崩溃。
