log.Printf 在 panic 后不输出是因为 panic 未 recover 时后续代码不执行；若已执行但无输出，可能是输出被设为 io.Discard、文件不可写或日志内容为 nil。
为什么 log.Printf 在 panic 后不输出？
Go 的 log 包默认写入 os.Stderr，但若程序在调用 log.Printf 前已触发 panic 且未 recover，后续日志语句根本不会执行。更隐蔽的情况是：你写了日志，但没看到输出——可能因为 log.SetOutput 被意外设为 ioutil.Discard（旧版）或 io.Discard（Go 1.16+），或者日志被重定向到文件但文件路径不可写。
- 检查是否在
init()或主流程早期调用了log.SetOutput(io.Discard) - 确认
log.Output调用的第 2 个参数（即日志内容）不是nil，否则会静默失败 - 若重定向到文件，用
os.OpenFile时加上os.O_CREATE | os.O_APPEND，并检查返回 error
如何让错误日志自动包含文件名和行号？
log 包本身不自动注入位置信息，需手动启用标志位。但要注意：log.Lshortfile 和 log.Llongfile 会轻微拖慢性能（每次调用都做运行时栈解析），线上高频日志建议关闭。
log.SetFlags(log.LstdFlags | log.Lshortfile)
log.Println("something went wrong") // 输出类似：2024/04/05 10:23:41 main.go:12: something went wrong
-
log.Lshortfile显示file:line，log.Llongfile显示完整路径 - 若用自定义 logger（如
log.New），必须显式传入 flags，例如：log.New(os.Stdout, "", log.LstdFlags|log.Lshortfile) - 第三方库如
zap或zerolog默认不带行号，需通过Caller()或With().Caller()显式开启
recover 捕获 panic 后怎么记录原始错误堆栈？
直接用 log.Println(r) 只能打出 panic 值（比如 "runtime error: index out of range"），丢失调用链。要用 debug.PrintStack() 或 runtime.Stack() 手动捕获。
defer func() {
if r := recover(); r != nil {
log.Printf("PANIC: %v", r)
log.Printf("Stack trace:\n%s", debug.Stack())
}
}()
-
debug.Stack()返回[]byte，需转string；它比runtime.Stack(buf, false)更简洁 - 避免在 defer 中直接调用
log.Fatal，否则会再次 panic，导致进程提前退出，堆栈来不及刷出 - 若用
zap，推荐logger.Panic("msg", zap.Any("err", r), zap.String("stack", string(debug.Stack())))
生产环境该不该用标准 log 包？
可以，但仅限低频、非关键服务。标准包没有结构化输出、无日志等级动态控制、不支持异步写入，高并发下 log.Printf 是同步阻塞的，可能拖慢主逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 日志量大时，
log的锁竞争会导致 goroutine 等待，可用zap.L().Sugar()替代，性能高一个数量级 - 需要按 level 过滤（如只保留 ERROR）？标准包做不到，得自己封装或换库
- 如果只是调试本地小工具，
log完全够用；但一旦涉及 HTTP 服务、定时任务、微服务间调用，建议从第一天就用zerolog或zap
最常被忽略的一点：无论用哪个库，所有日志语句里的变量都要提前评估好是否可能 panic —— 比如 log.Info("user", zap.String("name", user.Name()))，如果 user 是 nil，这行本身就会 panic，日志永远发不出去。
