runtime.Caller() 在新 goroutine 中无法回溯到外部函数的调用位置，因其栈帧独立；需在启动 goroutine 前捕获调用信息并显式传递，而非依赖 shift > 0 跨协程栈遍历。
`runtime.caller()` 在新 goroutine 中无法回溯到外部函数的调用位置，因其栈帧独立；需在启动 goroutine 前捕获调用信息并显式传递，而非依赖 `shift > 0` 跨协程栈遍历。
在 Go 中，每个 goroutine 拥有独立的调用栈。当你在 getFileName 中启动一个匿名函数 goroutine 后，该 goroutine 的栈顶是其自身入口，紧接着是运行时底层的 goexit（如 asm_amd64.s:1014），而原始调用点（如 main.go:11）完全不在该 goroutine 的栈上。因此，runtime.Caller(1) 或更高 skip 值必然失败或返回运行时内部文件——这并非 bug，而是 Go 并发模型的固有设计。
✅ 正确做法：在 goroutine 启动前捕获调用信息，并作为参数传入
package main
import (
"fmt"
"path/filepath"
"runtime"
"time"
)
func main() {
getFileName(2) // skip: 0→匿名函数内, 1→go func(), 2→main()调用处
time.Sleep(time.Second)
}
func getFileName(skip int) {
// ✅ 关键：在 goroutine 创建前获取 caller 信息
_, file, line, ok := runtime.Caller(skip)
if !ok {
file, line = "???", 0
} else {
file = filepath.Base(file)
}
// 将捕获的信息闭包进 goroutine
go func(f string, l int) {
fmt.Printf("Called from %s:%d\n", f, l) // 输出：Called from main.go:11
}(file, line)
}? 注意事项：
-
skip值需精确计算：0是runtime.Caller当前行，1是外层函数（如getFileName），2才是main中的调用点； - 不要尝试在 goroutine 内用
runtime.Caller(n)“穿透”到父 goroutine 栈——Go 运行时禁止且不支持； -
debug.PrintStack()等调试工具虽能显示 goroutine 创建位置（如created by main.getFileName），但其输出格式非结构化、不可靠，严禁用于生产逻辑判断； - 若需统一日志溯源，建议封装为带上下文的 helper 函数，例如：
func WithCaller(fn func(string, int)) {
_, file, line, ok := runtime.Caller(1)
if !ok {
file, line = "???", 0
} else {
file = filepath.Base(file)
}
fn(file, line)
}
// 使用
go func() {
WithCaller(func(f string, l int) {
log.Printf("task started at %s:%d", f, l)
})
}()总结：Go 的 goroutine 栈隔离保障了并发安全性，但也意味着调用链信息不会自动跨协程传递。开发者必须主动捕获、显式传递关键上下文——这是清晰、可控且符合 Go 设计哲学的实践方式。
