runtime.caller(1) 返回调用当前函数的上一层代码位置，即直接调用者的文件和行号；skip=1最常用，pc需减1才可安全用于funcforpc，buf须足够大且用n切片，stack(true)会stw应避免在热路径使用。
runtime.Caller(1) 返回的是谁？别拿错调用者位置
它返回的是调用当前函数的上一层代码位置，不是当前函数自己。比如你在封装的 logError 里写 runtime.Caller(1)，拿到的就是调用 logError 那行业务代码的文件和行号——这才是你真正想定位的源头。
-
skip = 0→ 返回runtime.Caller自身所在栈帧，基本没用 -
skip = 1→ 最常用，指向直接调用者 -
skip = 2→ 跳过一层封装（比如自定义 logger），但得确保调用链稳定，否则可能越界导致ok == false - 如果
ok == false，说明栈太浅或 goroutine 已结束，不能直接解包file或line，否则 panic
从 pc 拿函数名必须减 1，否则 runtime.FuncForPC 常返回 nil
runtime.Caller 返回的 pc 是调用点的指令地址，不是函数入口。直接传给 runtime.FuncForPC(pc) 在 Go 1.20+ 上大概率返回 nil，尤其开启内联优化时。
- 安全做法是
runtime.FuncForPC(pc - 1)，覆盖绝大多数情况 - 如果只要文件和行号，不用函数名，就完全跳过
FuncForPC这步 - 返回的函数名带完整包路径（如
"main.test"或"github.com/user/pkg.(*Client).Do"），要纯函数名得用strings.LastIndex截取最后一段 -
FuncForPC可能返回nil：CGO 环境、strip 符号表（-ldflags="-s -w"）、UPX 打包都会破坏元数据
runtime.Stack(buf, false) 容易截断，缓冲区大小不是猜的
它不报错也不提示，buf 太小就静默截断。常见现象是输出只有 runtime.goexit 一行，或者堆栈明显不全。
- 单 goroutine 堆栈通常几 KB，panic 场景可能超 100KB；建议起步用
make([]byte, 1024*1024)（1MB） - 必须用返回值
n切片：string(buf[:n])，不能直接string(buf)，否则残留旧数据 - 若
n == len(buf)，说明可能被截断，应扩大缓冲区重试 - 传
nil给 buf 会让 runtime 自己分配，但返回切片可能被 GC 回收，导致日志乱码或 panic
抓所有 goroutine 堆栈时，runtime.Stack(buf, true) 会 STW
它会暂停整个程序来遍历所有 goroutine，不是轻量操作。高并发服务里一次调用就可能拖慢调度器，甚至触发监控告警。
- 别在 HTTP handler、定时任务或高频路径里直接调用
runtime.Stack(buf, true) - 生产环境优先走
/debug/pprof/goroutine?debug=2，它做了流式输出和缓冲控制 - 如果真要自己抓，务必限频（如每分钟最多 1 次）、加超时、采样后才写日志
- 编译时去掉符号表（
-ldflags="-s -w"）会导致堆栈只显示地址，看不到函数名和行号
实际用的时候，最常踩的坑不是不会调 API，而是忘了 pc - 1、buffer 不够大、或在热路径反复 call runtime.Caller —— 它比普通函数慢 1–2 个数量级。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
