debug.printstack()适合开发期快速埋点，它不改代码结构、不依赖error、只输出当前goroutine调用链；但因输出到os.stderr、无格式无时间戳、无法接入日志系统，线上禁止使用。
别直接用 debug.PrintStack() 上生产——它只打当前 goroutine、输出到 stderr、没法接入日志系统，但开发期快速埋点确实省事。
debug.PrintStack() 适合什么场景
它就是个“临时探针”：不改代码结构、不依赖 error、不捕获 goroutine 全局状态，只在你想确认“此刻这个 goroutine 调用链长啥样”时，插一行就跑。
- 常见错误是把它塞进 HTTP handler 主路径里——每次请求都打，stderr 冲垮、日志混杂、还看不出协程竞争
- systemd 或容器环境常重定向 stderr，
debug.PrintStack()输出可能直接丢弃，根本看不到 - 它不带时间戳、不带 caller 标识、不格式化，和
log.Printf混在一起时，容易被当成普通日志忽略 - 只输出当前 goroutine，比如你在中间件里调用，看到的只是中间件自己的栈，不是下游 handler 的
panic 恢复时为什么必须用 debug.PrintStack() 或 debug.Stack()
Go 默认 panic 输出只显示最后一层（比如 index out of range），没上下文。recover 后不主动抓栈，等于丢掉现场。
- 必须放在
defer func() { if r := recover(); r != nil { ... } }()里，且在recover()之后立刻执行 -
debug.PrintStack()简单粗暴，但输出不可控；更推荐debug.Stack()+string()转成字符串再交由 log 处理 - 注意：
debug.Stack()返回的[]byte底层内存可能被 GC 回收，不能直接传给异步写入逻辑——要立刻转成独立字符串，例如s := string(debug.Stack()) - 如果堆栈超长（嵌套深、函数名长、变量打印多），
debug.Stack()默认用 4KB 缓冲区，会静默截断，只留runtime.goexit这类顶层帧
runtime.Stack(buf, false) 替代 debug.Stack() 的实操要点
想避免截断又不想依赖 debug.Stack() 的固定缓冲区，就得自己分配 buf 并调 runtime.Stack()。
- 缓冲区至少设为
make([]byte, 1024*1024)（1MB），深度嵌套或大量 goroutine 本地变量时建议 2MB - 第二个参数为
false（默认）时只抓当前 goroutine；设为true会 STW 扫描全部 goroutine，线上慎用 - 调用后检查返回值
n：if n == len(buf) { /* 被截断 */ }，此时可考虑降级处理（比如只记录长度+警告，不重试） - 拿到
n后立刻做string(buf[:n])，确保内容脱离 runtime 临时分配内存，避免 GC 导致乱码或空内容
线上环境该用什么替代 PrintStack 和 Stack
所有同步抓全量 goroutine 堆栈的操作，在高并发下都有风险：runtime.Stack(buf, true) 可能卡住调度器几十毫秒，debug.PrintStack() 无法收敛。
- 优先走
/debug/pprof/goroutine?debug=2HTTP 接口，它底层封装了流式写入+合理采样，开销可控 - 程序内触发可用
pprof.Lookup("goroutine").WriteTo(w, 2)，把w指向文件、HTTP response body 或 buffer，自主控制输出目标 - 信号触发（如
SIGUSR1）比定时 dump 更安全，避免干扰正常请求流程 - 死锁诊断不要靠反复调
runtime.Stack，而应结合go tool trace或 pprof 的 goroutine profile 差分分析
真正难的不是“怎么调函数”，而是判断该在哪一刻、以什么粒度、对谁抓栈——goroutine 状态不稳定时抓，结果不可信；缓冲区大小没对齐实际深度，信息就残缺；没隔离 stderr 重定向，日志就消失。这些细节不处理，堆栈信息再全也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
