runtime.stack 默认返回空或截断，因缓冲区仅4kb且默认只捕获当前goroutine；应设buf≥64kb、第二个参数为true，并在受控入口安全调用。
runtime.Stack 默认只抓当前 goroutine、缓冲区仅 4KB，绝大多数情况返回空或截断——别怪它不工作，是调用方式错了。
为什么 runtime.Stack 经常返回空或长度为 0？
根本原因有两个：缓冲区太小 + 默认只捕获当前 goroutine。
-
runtime.Stack第二个参数为false（默认）时，只写入当前 goroutine 的栈；若该 goroutine 刚启动、没多少调用帧（比如在main函数开头就调），结果就是几行 runtime 初始化代码，甚至 0 字节 - 底层缓冲区默认上限是 4KB，稍深一点的嵌套调用（如 HTTP handler → service → repo → DB query）就直接溢出，
runtime.Stack返回实际写入字节数，小于 buf 长度即表示被截断 - 在
defer中 panic 后调用，部分 goroutine 可能已退出，堆栈结构不稳定，结果不可靠
如何安全获取全部 goroutine 的完整堆栈？
关键不是“怎么调”，而是“谁来调、何时调、buffer 多大”。
- buf 至少要
make([]byte, 64*1024)；死锁诊断建议用2 * 1024 * 1024（2MB），覆盖数千 goroutine 没压力 - 第二个参数必须为
true：runtime.Stack(buf, true)才会遍历所有 goroutine - 避免在高并发热路径频繁调用——它是同步操作，
all=true时需暂停调度器扫描全部 G 结构体，可能卡住几十毫秒 - 生产环境推荐只在受控入口触发：比如
SIGQUIT信号 handler、/debug/pprof/goroutine?debug=2端点、或人工介入排查时的临时 HTTP 接口
runtime.Stack 和 pprof.Lookup("goroutine").WriteTo 有什么区别？
不是替代关系，是用途错位：一个看「此刻谁卡在哪」，一个查「谁不该长期存在」。
-
runtime.Stack(buf, true)输出的是带源码文件名和行号的完整文本堆栈（类似 panic 输出），能清晰看到每个 goroutine 停在select、chan receive还是sync.Mutex.Lock -
pprof.Lookup("goroutine").WriteTo(w, 1)输出的是采样摘要，默认只包含running/syscall/waiting状态的 goroutine，且不含文件名和行号；适合做 goroutine 泄漏分析（多次快照 diff） - HTTP 暴露堆栈？直接用
/debug/pprof/goroutine?debug=2，它底层就是封装好的runtime.Stack，已处理 buffer 分配和 charset
panic 时如何拿到真正有用的堆栈？
别依赖 panic 默认输出——它只显示最后一层。要看到完整链路，必须自己动手。
- 在顶层
defer+recover里调debug.PrintStack()或string(debug.Stack())，否则日志里只有index out of range这种信息 -
debug.PrintStack()直接写os.Stderr，若服务重定向了 stderr（如 systemd），建议改用debug.Stack()转字符串后交由 log 库输出 - 注意：
debug.Stack()拿到的是「recover 发生点」的堆栈，不是 panic 最初发生的点；若错误层层返回，这里记录的是最后处理它的位置 - 想保留原始错误上下文？用
github.com/pkg/errors.Wrap(err, "xxx")或 Go 1.20+ 的fmt.Errorf("xxx: %w", err)，再配合%+v格式化打印，能显示包装链和各层堆栈
最易被忽略的一点：堆栈本身不告诉你变量值，只告诉你调用时的地址快照；看到 0x0 在第一个位置，99% 是 nil 接收者解引用，别浪费时间查参数——先检查那个 *T 是不是忘了初始化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
