runtime.Caller(0)返回自身位置，实际定位错误应使用runtime.Caller(1)获取调用者文件名、行号；需检查ok布尔值，函数名须配合runtime.FuncForPC(pc-1)安全解析，避免nil；debug.PrintStack适合调试，生产环境应使用runtime.Stack(buf, false)捕获当前goroutine栈。
如何用 runtime.Caller 获取当前调用栈帧
直接调用 runtime.Caller(0) 能拿到当前函数的文件名、行号和函数名，但要注意参数含义：0 表示当前帧（即 Caller 自身），1 才是调用它的上一层函数。实际定位错误时几乎总该用 1 或更大值。
常见误用是写成 runtime.Caller(0) 后去解析返回值，结果得到的是 runtime.Caller 的位置，而非业务代码位置。
-
runtime.Caller(0)→ 返回runtime.Caller函数内部的位置 -
runtime.Caller(1)→ 返回调用它的那行代码位置（推荐起点） - 第三个返回值是
bool，务必检查是否为true，否则file和line不可信
打印完整调用栈：用 runtime.Stack 还是 debug.PrintStack？
debug.PrintStack() 最简单，直接输出到 os.Stderr，适合临时调试；但无法捕获字符串、不能定制输出目标。真正需要日志记录或上报时，得用 runtime.Stack。
runtime.Stack 第一个参数是 []byte 切片，传 nil 会自动分配足够空间；第二个参数若为 true，会抓取所有 goroutine 栈，非常重，生产环境慎用；false 只抓当前 goroutine，更安全。
立即学习“go语言免费学习笔记（深入）”；
- 临时调试：直接写
debug.PrintStack()，一行搞定 - 写入日志：用
buf := make([]byte, 1024*64); n := runtime.Stack(buf, false)</li> <li>避免 panic：<code>buf
太小会导致截断，建议至少64KB起步
在 panic 恢复中获取栈信息：为什么 recover() 后再调用 runtime.Caller 会失效？
recover() 只能捕获 panic 时的栈顶状态，但一旦执行了 recover()，当前 goroutine 就退出了 panic 状态，再调用 runtime.Caller 得到的是 recover 调用点，不是 panic 发生点。
正确做法是在 defer + recover 闭包里，立刻用 runtime.Caller(1) 或配合 runtime.Stack 抓取，而不是等 recover 后再查。
- 错误写法：
if r := recover(); r != nil { log.Printf("panic: %v at %s:%d", r, file, line) }—— 此时file/line是 recover 所在行 - 正确写法：在 defer 里先调用
runtime.Stack，或用runtime.Caller(1)记录 panic 前最后一行业务代码 - 注意：panic 本身不带栈，
recover()返回值只是 panic 参数，栈信息必须额外采集
性能与兼容性：频繁调用 runtime.Caller 会影响 GC 吗？
会，但影响有限。每次 runtime.Caller 都要遍历 PC（程序计数器）查找符号信息，底层依赖 runtime.findfunc 和符号表查询，在高并发或高频日志场景下可能成为瓶颈。
Go 1.20+ 对 runtime.Caller 做了优化，但仍有可观开销。如果只是开发期调试，没问题；线上开启全量栈采集（尤其 runtime.Stack(true)）会显著拖慢吞吐、增加内存压力。
- 线上建议：只在关键错误路径（如不可恢复 panic）采集栈，且用
runtime.Stack(buf, false) - 避免在 hot path（如每请求都调用）中使用
runtime.Caller - 交叉编译或 strip 符号后，
runtime.Caller仍能返回文件行号，但函数名可能为空（取决于 build flag）
栈信息不是“调用链路快照”，而是运行时动态解析的结果；同一行代码在不同 goroutine 或不同优化等级下，解析出的函数名可能不同。别依赖函数名做逻辑判断，文件+行号才可靠。
