runtime.Caller() 在新 goroutine 中无法回溯到原始调用点（如 main.go:11），因其栈帧独立；shift=1 实际指向底层 goexit 汇编函数，而非用户代码。需在启动 goroutine 前捕获调用位置，或改用 debug.PrintStack() 辅助诊断。
`runtime.caller()` 在新 goroutine 中无法回溯到原始调用点（如 `main.go:11`），因其栈帧独立；`shift=1` 实际指向底层 `goexit` 汇编函数，而非用户代码。需在启动 goroutine 前捕获调用位置，或改用 `debug.printstack()` 辅助诊断。
在 Go 中，runtime.Caller(skip int) 用于获取当前 goroutine 栈帧中指定深度的源码位置（文件名、行号）。但关键前提是：它仅能遍历当前 goroutine 的执行栈。当通过 go func() { ... }() 启动新协程时，该 goroutine 拥有完全独立的栈——其最顶层是运行时的 goexit 函数（如 asm_amd64.s:1014），紧接着才是匿名函数自身，而原始调用者（如 main()）根本不在这个栈上。因此，无论 skip 设为 1、2 或更大值，都不可能得到 main.go:11 这样的结果。
✅ 正确做法：在 goroutine 启动前捕获调用信息
若需在异步逻辑中保留原始调用上下文，应在 go 语句执行前调用 runtime.Caller，并将结果作为参数传入闭包：
func getFileName(shift int) {
// ✅ 在 goroutine 创建前获取调用位置
_, file, line, ok := runtime.Caller(shift + 1) // +1 补偿 getFileName 自身调用层
if !ok {
file, line = "???", 0
}
file = filepath.Base(file)
go func(f string, l int) {
fmt.Printf("%s:%d\n", f, l) // 输出如 main.go:11
}(file, line)
}
? 注意：
shift + 1是因为runtime.Caller被调用在getFileName内部，需额外跳过这一层才能抵达main()调用点。
⚠️ 不推荐依赖 debug.PrintStack() 生产环境使用
虽然 debug.PrintStack() 可打印包含“created by”信息的完整堆栈（含 goroutine 创建位置），但其输出格式非结构化、性能开销大，且文档明确说明：该功能专为调试设计，行为不保证跨版本稳定，不应在生产逻辑中解析或依赖。
// 仅用于临时调试，勿用于日志或错误处理主逻辑
go func() {
debug.PrintStack() // 输出含 "created by main.getFileName" 的堆栈
}()
? 补充说明：为什么 runtime.Caller(1) 返回汇编文件？
Go 的每个 goroutine 启动时，运行时会将 goexit（架构相关汇编函数）压入栈底，作为协程生命周期的“根”。runtime.Caller(0) 指向匿名函数内 Caller 调用行；Caller(1) 则指向 goexit 入口——这是设计使然，并非 bug。
✅ 总结建议
-
永远不要期望在 goroutine 内用
runtime.Caller回溯到父 goroutine 的调用点； -
必须传递上下文：在
go语句前捕获file/line并显式传参； -
避免解析调试输出：
debug.PrintStack()仅作人工排查，不可用于自动化逻辑； -
考虑更高层抽象：如需统一追踪异步调用来源，可结合
context.Context携带元数据，或使用 OpenTelemetry 等可观测性工具。
这样，你既能保持匿名函数的简洁性，又能精准获取预期的源码位置信息。
