log.printf 仅输出日志，程序继续执行；log.fatal 输出日志后调用 os.exit(1) 终止进程，仅应用于初始化失败等不可恢复场景。
log.Printf 和 log.Fatal 有什么关键区别
区别在于程序是否继续执行：log.Printf 只输出日志，之后代码照常运行；log.Fatal 输出日志后会调用 os.Exit(1)，直接终止进程。错误处理中误用 log.Fatal 是常见问题——比如在 HTTP handler 里记录一个参数解析失败就退出整个服务，显然不合理。
实际建议：
- 仅在初始化失败（如配置加载、端口绑定）等真正无法继续运行时用
log.Fatal - 业务逻辑中的错误一律用
log.Printf或更明确的log.Println，并配合return显式退出当前函数 - 若需带堆栈，
log.Printf不自带，得手动加debug.PrintStack()或换用第三方库
为什么 errors.Wrap 后的日志看不出原始错误位置
errors.Wrap（来自 github.com/pkg/errors）能附加上下文，但默认日志输出不显示堆栈。你写 log.Printf("failed: %v", err)，只打印错误消息，不触发堆栈格式化。
正确做法是用 %+v 动词：
立即学习“go语言免费学习笔记（深入）”；
err := errors.Wrap(io.EOF, "reading header")
log.Printf("error: %+v", err) // 才会打印完整堆栈
注意：%+v 是 github.com/pkg/errors 特有的行为，标准库 errors（Go 1.13+）不支持。如果混用 fmt.Errorf("...: %w", err)，仍需靠 %+v 配合该包才能看到帧信息。
log.SetOutput(os.Stderr) 还需要设置吗
默认就是 os.Stderr，所以绝大多数情况不用显式设置。但容易被忽略的是：一旦你调用了 log.SetOutput 指向文件或缓冲区，后续所有 log.Printf 都会写入那里——包括第三方库内部用的 log 包（比如 net/http 的某些调试日志）。
如果你只是想分离“应用错误日志”和“标准输出”，更安全的做法是：
- 不要动全局
log实例，改用自定义 logger：log.New(file, "[ERROR] ", log.LstdFlags) - 避免依赖
log.SetOutput，尤其在库代码中——它有副作用，影响其他模块 - 若必须重定向，确保在
main()最早处设置，且不被子包覆盖
zap.Logger 里 Errorw 和 Error 传参方式为何不同
zap.Errorw 是 zap 提供的结构化日志快捷方法，本质是 Error + With 的组合，但它的参数顺序和语义固定：msg 必须是第一个字符串，后面必须是键值对（偶数个参数）。
logger.Errorw("db query failed", "sql", sql, "err", err) // ✅ 正确
logger.Error("db query failed", err) // ❌ 编译失败：Error 只接受 msg string
真正对应标准库 log.Printf 行为的是 logger.Warnf 或 logger.Errorf，它们支持格式化字符串。而 logger.Error 只接收一个 error 类型参数，用于自动提取堆栈和字段，不能传字符串消息。
容易踩的坑：
- 把
logger.Errorw("msg", err)写成两个参数，漏掉键名，导致日志字段错位 - 误以为
Errorw能自动展开err的堆栈——其实要额外加zap.Error(err)字段才完整 - 在高并发场景下频繁调用
Errorw传大量字符串，产生不必要的内存分配
fmt.Sprintf 拼接。 
