panic堆栈默认含真实文件名和行号，但recover后需立即用runtime.caller(1)获取，因0指向recover函数本身；避免log.panicln等包装导致行号被覆盖。
panic时如何拿到真实的文件名和行号
默认情况下，panic 打印的堆栈信息里确实包含触发位置，但如果你用 recover 捕获后自己处理，就容易只看到 runtime.gopanic 这类内部调用——行号会丢失。关键不是“能不能”，而是“怎么避免被 runtime 的调用帧遮盖”。
- 必须在
panic发生**后立即**调用recover()，且不能跨 goroutine；延迟函数（defer）是唯一可靠入口点 - 用
runtime.Caller(1)而不是0：因为0指向recover所在函数本身，1才指向真正触发panic的那行 - 别依赖
fmt.Printf("%+v", err)—— 它对自定义 error 类型可能不输出行号，而原生panic的堆栈才是最准的源
用runtime.Caller手动提取行号的最小可行写法
这是最轻量、不依赖第三方包的方式，适合嵌入已有错误处理逻辑：
func safeDo() {
defer func() {
if r := recover(); r != nil {
// 获取 panic 发生处的文件和行号
_, file, line, ok := runtime.Caller(1)
if !ok {
file = "unknown"
line = 0
}
log.Printf("panic at %s:%d: %v", file, line, r)
}
}()
// 可能 panic 的代码
panic("something went wrong")
}
注意：runtime.Caller(1) 返回的 file 是绝对路径，生产环境常需用 filepath.Base(file) 截取文件名。
为什么log.Panicln不直接给出行号
log.Panicln 底层仍是调用 panic，但它把原始 panic 值包装成字符串再 panic，导致调用栈顶变成 log.Panicln 自身，runtime.Caller(1) 就指向它了。真实行号被盖住。
- 现象：你看到的 panic 位置是
log.go:321，而不是你写log.Panicln的那行 - 解法：要么不用
log.Panic*系列，改用log.Println+ 显式panic()；要么自己封装一个带 caller 信息的 panic 函数 - 替代方案示例：
panic(fmt.Sprintf("[%s:%d] %v", filepath.Base(file), line, msg))，但这样会丢失原始 panic 类型，recover()拿到的是字符串而非 error 接口
调试阶段快速定位 panic 行号的命令行技巧
不改代码也能看到完整堆栈——关键是让 Go 运行时不截断：
- 运行时加环境变量：
GOTRACEBACK=2 go run main.go（1是默认值，2会展开所有 goroutine 的栈） - 如果 panic 发生在测试中：
go test -v -run=TestName 2>&1 | grep -A 20 "panic"，配合-gcflags="-l"关闭内联，能让行号更准 - 注意：CGO_ENABLED=0 会影响某些底层调用栈展示，交叉编译时若行号异常，先确认是否启用了 cgo
真正难的不是获取行号，而是当 panic 被多层 defer 包裹、或发生在 http handler 的 goroutine 里时，Caller 的层级偏移容易算错——这时候别猜，用 debug.PrintStack() 直接看全栈更省事。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
