错误信息被截断因log.Printf默认不展开error结构，仅调用Error()方法；应使用%+v并配合Go 1.13+ errors包或pkg/errors库，或显式递归Unwrap；开启log.Lshortfile可显示文件行号，但需注意封装干扰；log.Fatal可能丢日志因os.Exit不刷新缓冲区，推荐先log再os.Exit。
log.Printf 和 error 一起用时，为什么错误信息总被截断？
因为 log.Printf 默认不展开 error 类型的底层结构，直接传入 err 只会调用其 Error() 方法返回字符串，丢失堆栈、嵌套错误等上下文。尤其在用 fmt.Errorf("failed: %w", err) 包装后，单纯 log.Printf("%v", err) 无法显示原始错误链。
- 正确做法是用
%+v格式符（需配合支持错误展开的库，如github.com/pkg/errors或 Go 1.13+ 的errors.As/errors.Unwrap） - 更推荐：统一用
log.Printf("failed to do X: %+v", err)+ 启用-gcflags="all=-l"避免内联干扰堆栈捕获（仅调试期） - 生产环境别依赖
%+v，改用显式提取：先判断是否实现了interface{ Unwrap() error }，再递归打印
如何让 log 输出包含文件名和行号？
标准库 log 支持通过 log.SetFlags() 开启位置标记，但默认关闭。开启后，每条日志开头会追加 file:line，对定位错误源头非常关键。
log.SetFlags(log.LstdFlags | log.Lshortfile)
log.Println("something happened") // 输出类似：2024/04/05 10:23:41 main.go:12: something happened
-
log.Lshortfile显示相对路径（如main.go:12），log.Llongfile显示绝对路径 - 注意：
log.Lshortfile在跨包调用时可能指向日志封装函数而非真实出错位置，此时应避免二次封装log.Printf，或改用runtime.Caller手动获取 - 如果用了
log.New自定义 logger，必须对每个实例单独调用SetFlags
error 能否直接塞进 log.Printf 的格式化参数而不转成字符串？
可以，但要区分场景：
- 纯值传递没问题：
log.Printf("connect failed: %v", err)—— 这里err是接口类型，log内部会调用err.Error() - 若想保留错误类型用于后续判断（比如重试逻辑），不要提前转成
err.Error()，否则丢失类型信息和可比性 - 切忌这样写：
log.Printf("error: %s", err.Error())—— 多余且当err == nil时 panic - 更安全的 nil 检查模式：
if err != nil { log.Printf("operation failed: %v", err) return err }
为什么用 log.Fatal(err) 后程序没输出就退出了？
log.Fatal 内部调用 os.Exit(1)，它不等待 stdout 缓冲区刷新，导致最后几条日志（尤其是刚写入还没 flush 的）丢失。常见于容器环境或重定向到文件时。
立即学习“go语言免费学习笔记（深入）”；
-
解决方法一：手动 flush：
log.SetOutput(os.Stderr) // 确保输出到 stderr log.SetFlags(log.LstdFlags | log.Lshortfile) log.Fatal(err) // 仍可能丢，不推荐
- 解决方法二（推荐）：拆成两步 —— 先 log，再 os.Exit：
if err != nil { log.Printf("fatal error: %+v", err) os.Exit(1) } - 根本规避方式：不用
log.Fatal，改用返回错误 + 主函数统一处理，符合 Go 错误处理惯用法
%+v，如果错误在 goroutine 中生成而主流程已退出，照样看不到堆栈。这时候得配合 sync.WaitGroup 或 context 控制生命周期，而不是只盯着 log 函数怎么写。 
