runtime.stack 经常返回空或截断堆栈，因其默认仅捕获当前 goroutine 且受缓冲区大小限制；传 nil 或过小 buf 会导致截断或乱码，需预分配足够空间（如 1mb），获取全量堆栈须传 true 但有 stw 风险，推荐优先使用 pprof。
runtime.Stack 为什么经常返回空或截断的堆栈
runtime.Stack 默认只捕获当前 goroutine 的堆栈，且会受 buf 长度限制——如果传入的 []byte 不够大，它就直接截断，不报错也不提示。很多人调用后发现输出只有几行，甚至为空，其实是缓冲区太小。
常见错误现象：runtime.Stack 返回长度远小于预期，或只显示 runtime.goexit 一行；调试时想看所有 goroutine 堆栈却只拿到当前的。
- 必须预先估算足够大的缓冲区，比如
make([]byte, 64*1024)（64KB）起步，生产环境建议 1MB - 要获取所有 goroutine 堆栈，得传
true作为第二个参数：runtime.Stack(buf, true) - 注意：
runtime.Stack是同步阻塞调用，若在高并发、低延迟场景频繁调用，可能拖慢调度器
如何安全地打印当前 goroutine 的完整堆栈
最常用也最容易出错的场景：panic 捕获后想记录堆栈，但直接用 debug.PrintStack() 会输出到 os.Stderr，不可控；而 runtime.Stack 返回的是原始字节，需要手动转字符串并处理换行。
使用场景：日志中间件、panic 恢复钩子、性能采样点。
立即学习“go语言免费学习笔记（深入）”；
- 推荐写法：
buf := make([]byte, 1024*1024) n := runtime.Stack(buf, false) log.Printf("stack: %s", string(buf[:n])) - 不要用
string(runtime.Stack(nil, false))——nil会让函数自己分配，但返回的切片可能被后续 GC 回收，导致日志内容乱码或 panic - 如果只是临时调试，
debug.PrintStack()更快，但它绕过日志系统，不适合线上
runtime.Stack(true) 在生产环境的风险
传 true 会让 runtime.Stack 遍历所有 goroutine 并拼接堆栈，这在 goroutine 数量多（比如上万）时开销极大：不仅内存暴涨，还会暂停整个程序（STW 片段变长），可能触发超时或被监控误判为卡顿。
性能影响明显：实测 10k goroutine 下，runtime.Stack(buf, true) 耗时可达 50–200ms，而 false 通常在 0.1ms 内。
- 线上禁止在请求处理路径中调用
runtime.Stack(buf, true) - 如需分析 goroutine 泄漏，优先用
pprof/goroutine接口（/debug/pprof/goroutine?debug=2），它更轻量且支持采样 - 若必须用
runtime.Stack抓全量，应加限流和超时，例如用time.AfterFunc包裹，超时直接放弃
替代方案：用 pprof 抓 goroutine 堆栈更可靠
直接调 runtime.Stack 是“硬抓”，而 net/http/pprof 提供了经过优化的 goroutine 堆栈导出逻辑，支持文本/压缩格式、按状态过滤（如 goroutine?debug=1 只显示正在运行的），还自带 HTTP 权限和速率控制。
使用场景：运维巡检、CI 自动化检测 goroutine 泄漏、APM 集成。
- 启动时注册：
import _ "net/http/pprof" go http.ListenAndServe("localhost:6060", nil) - 获取精简堆栈：
curl 'http://localhost:6060/debug/pprof/goroutine?debug=1' - 注意：默认
?debug=2输出全部 goroutine（含等待中），体积大；?debug=1更适合快速定位阻塞点
真正难的不是怎么拿到堆栈，而是怎么在不干扰系统的情况下拿到「有用的」那一部分——缓冲区大小、goroutine 范围、调用时机，这三个点没对齐，堆栈信息反而会成为噪音源。
