禁用 runtime.stack(buf, true)，因其触发 stw 致服务暂停；优先用 /debug/pprof/goroutine?debug=2；runtime.stack(buf, false) 需足量缓冲并检查截断；慎用 runtime.caller(1)，高频场景改用 errors.wrap 或 fmt.errorf(%w)。
runtime.Stack(buf, true) 会卡住整个服务，不是慢，是暂停
线上绝对禁用 runtime.Stack(buf, true)。它不是“耗时稍长”，而是触发 Stop-The-World：所有 goroutine 瞬间停摆，调度器冻结，netpoll 和 timer 全部卡住。实测 10k goroutine 时 STW 耗时 50–200ms，HTTP P99 直接翻倍，下游熔断可能被连带触发。
常见错误现象：runtime.Stack(buf, true) 调用后监控看到 CPU 突降、GC Pause 报警联动、select{default:} 意外跳过、定时器延迟超 100ms。
- 别把它和
/debug/pprof/goroutine?debug=2混为一谈——后者是采样式、限流保护、异步写入的调试接口 - 缓冲区太小（比如只给 4KB）会导致
runtime.Stack返回截断结果（n == len(buf)），重试扩容等于再进一次 STW，开销翻倍 - 真正要查 goroutine 泄漏，请 curl
/debug/pprof/goroutine?debug=2，而不是在代码里埋runtime.Stack(buf, true)
runtime.Stack(buf, false) 的缓冲区大小必须够用，否则静默丢栈
runtime.Stack(buf, false) 虽不触发全量 STW，但仍有可观开销（单次约 0.1–5ms，取决于当前 goroutine 栈深度），且缓冲区不足时不会报错，只会静默截断——返回的 n 等于 len(buf)，你根本不知道丢了什么。
典型踩坑：panic 恢复中只分配 4KB 缓冲，结果日志里只看到 runtime.goexit 一行，误判为“无调用上下文”。
- 保守起见，当前 goroutine 栈一般不超过 8KB；若调用链深（如模板渲染、嵌套 defer），建议预留 64KB+
- 务必检查返回值：
if n == len(buf) { log.Warn("stack truncated") } - 别传
nil：虽然函数会自动分配，但返回切片底层数组可能被 GC 回收，导致日志乱码或 panic
runtime.Caller(1) 开销远超直觉，高频日志里慎用
runtime.Caller(1) 不是读寄存器，而是完整遍历调用栈帧、解析符号表、匹配函数元数据，单次耗时 80–120ns。QPS 10k 的服务，每条日志都打一次，纯堆栈开销就超 1ms/秒，pprof 里 runtime.callers 占比飙升，GC 压力同步上升。
更隐蔽的问题是 skip 设错：它跳的是调用栈层数，不是“业务层”，而是包括 runtime 内部封装。在封装好的 Log.Info() 里写 runtime.Caller(1)，拿到的是 Log 方法自己的位置，不是业务调用点。
- 直接业务函数里用：
runtime.Caller(1) - 封装在日志方法内：
runtime.Caller(2)或3（视是否经过log.Output等标准库转发） - defer + recover 后取 panic 位置：
runtime.Caller(2)（recover 占 1 层，panic 触发点再上 1 层） - 别拆成三次调用：
runtime.Caller(1)一次就能拿到file、line、funcName，重复调用等于开销翻倍
打印错误堆栈的真正低成本路径：用 errors.Wrap + %+v，而非 runtime.Stack
fmt.Printf("%+v", err) 没堆栈，不是因为你没调对，而是 errors.New("xxx") 根本没存堆栈帧。只有 github.com/pkg/errors.Wrap 或 Go 1.20+ 的 fmt.Errorf("msg: %w", err) 在构造时主动调用 runtime.Callers，才能让 %+v 展开。
高频错误日志里硬塞 runtime.Stack 是杀鸡用牛刀。正确做法是统一包装：
- 业务函数返回前：
return errors.WithStack(err)（仅非 nil 时） - HTTP handler 入口 defer recover 时，用
runtime.Stack(buf, false)捕获 panic，但仅用于 crash 场景，不用于普通 error - 结构化日志（如 zap）直接传
zap.Error(err)，它会自动提取 pkg/errors 或自定义 error 的堆栈字段 - 完全不用第三方？可手写最小闭环：用
runtime.Caller(1)获取位置，封装进自定义 error 类型，但注意 skip 值别设错
真正麻烦的从来不是“怎么打堆栈”，而是“什么时候不该打”——STW 不可逆、Caller 开销可累积、缓冲区截断不可见。这些细节一旦漏掉，排查成本远高于问题本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
