默认情况下 runtime.caller(0) 返回当前函数首行位置，需用 runtime.caller(1) 才能获取调用方行号；多层封装时需按栈深度调整参数（常见 1～3）；与反射组合可获函数名和调用位置，但需注意内联影响；panic 恢复中应提前捕获位置；性能开销大，避免 hot path 频繁调用；跨平台路径格式不同，需归一化处理。
Go 里用 runtime.Caller 拿不到调用方行号？
默认情况下，runtime.Caller(0) 返回的是当前函数内部的行号，不是调用它的那行——这是最常踩的坑。想定位到“谁调用了我”，得往上跳一层。
-
runtime.Caller(0)：返回当前函数第一行的位置（比如函数开头的{） -
runtime.Caller(1)：才真正对应调用该函数的那行代码 - 如果封装了多层包装函数（比如日志 wrapper），要根据实际调用栈深度调整参数，常见值是
1～3
反射 + runtime.Caller 怎么组合用？
反射本身不提供源码位置信息，必须靠 runtime.Caller 补足。典型场景是写通用调试工具或自定义断言函数，需要同时知道“哪个函数被调了”和“在哪儿被调的”。
- 先用
runtime.Caller(1)拿到pc, file, line, ok - 再用
runtime.FuncForPC(pc)获取函数对象，调.Name()得到完整函数名（含包路径） -
file是绝对路径，如需相对路径可手动截掉$GOPATH/src/或用filepath.Rel - 注意：
pc在内联优化后可能不准，加//go:noinline注释可强制禁用内联
runtime.Caller 在 panic 恢复时行为异常？
在 recover() 中直接调 runtime.Caller，很可能拿到的是 defer 函数或 recover 自身的位置，而不是 panic 发生点。
- 正确做法：在 panic 前就用
runtime.Caller(2)（甚至更高）捕获原始位置，并存到上下文或 error 中 - 或者用
debug.PrintStack()辅助定位，但它输出到 stderr，不适合结构化处理 - goroutine 多时，
runtime.Caller返回的file和line仍是当前 goroutine 的，这点很稳定
性能和跨平台兼容性要注意什么？
runtime.Caller 是运行时系统调用，开销比普通函数大一个数量级，频繁调用会明显拖慢程序。
- 别在 hot path（比如每毫秒执行的循环里）反复调用；考虑缓存或只在 debug 模式启用
- Windows 下返回的
file路径含反斜杠\，Linux/macOS 是正斜杠/，做字符串匹配前先 normalize - 交叉编译时（如 darwin/amd64 → linux/arm64），
runtime.Caller行为一致，但file路径取决于构建环境，不是目标环境
真正难的不是怎么拿到行号，而是判断该跳几层、在哪一层拿、以及拿完之后要不要做路径清洗或函数名裁剪——这些都得看具体封装层级和部署方式。
