在 Go 中，runtime.Caller 在新 goroutine 中无法直接回溯到外部函数的调用位置（如 main.go:11），因为每个 goroutine 拥有独立栈；skip > 0 时会越界或返回运行时底层文件（如 asm_amd64.s），而非预期的业务代码位置。
在 go 中，`runtime.caller` 在新 goroutine 中无法直接回溯到外部函数的调用位置（如 `main.go:11`），因为每个 goroutine 拥有独立栈；`skip > 0` 时会越界或返回运行时底层文件（如 `asm_amd64.s`），而非预期的业务代码位置。
当你在匿名函数中调用 runtime.Caller(n) 时，你实际查询的是当前 goroutine 的执行栈，而非创建该 goroutine 的父函数调用栈。例如以下典型误用：
func getFileName(shift int) {
go func() {
_, file, line, ok := runtime.Caller(shift)
if !ok {
fmt.Printf("????:0\n")
return
}
fmt.Printf("%s:%d\n", filepath.Base(file), line)
}()
}
此处 shift = 1 本意是跳过 runtime.Caller 自身（skip=0）再向上查一层（即期望得到 getFileName 的调用点），但因 goroutine 栈为空（仅含 goexit 和匿名函数入口），runtime.Caller(1) 实际指向运行时汇编桩函数（如 asm_amd64.s:1014），这是 Go 调度器实现细节，不可靠且不应依赖。
✅ 正确解法：在启动 goroutine 前捕获调用信息，并显式传入
func getFileName() {
// 在当前 goroutine 中获取真实调用位置（main.go 第11行）
_, file, line, ok := runtime.Caller(1) // skip 1 → 调用 getFileName 的那行
if !ok {
file, line = "???", 0
}
fileName := filepath.Base(file)
// 将已解析的文件名与行号传递给 goroutine
go func(f string, l int) {
fmt.Printf("%s:%d\n", f, l) // 输出：main.go:11
}(fileName, line)
}
⚠️ 注意事项：
-
runtime.Caller(n)的n是相对于当前 goroutine 栈顶的偏移，与“谁启动了我”无关； -
debug.PrintStack()或runtime.Stack()可打印包含created by的完整堆栈（含 goroutine 创建点），但其输出格式非结构化、含实现细节，仅适用于调试，禁止用于生产逻辑判断； - Go 标准库不提供跨 goroutine 获取创建者源码位置的稳定 API——这是设计使然，避免运行时开销与语义耦合。
? 总结：若需在异步任务中记录来源位置，请遵循「捕获在前、传递在后」原则。在调用 go func() { ... }() 之前，用 runtime.Caller(1)（或更高 skip 值）获取并保存所需上下文，再通过闭包或参数注入到 goroutine 中。这既符合 Go 的并发模型本质，也保证了结果的确定性与可移植性。
