Go标准日志需用log.SetFlags()控制前缀标志位、log.SetOutput()接管写入逻辑来自定义格式；JSON日志须绕过标准log改用zerolog等结构化库；HTTP panic捕获应构造结构化日志而非拼接字符串；自定义错误类型需显式注入字段，跨goroutine需显式传递context。
Go标准日志如何替换默认格式
Go的log包默认输出带时间戳、文件名和行号，但不支持直接修改字段顺序或删减内容。想自定义格式，不能靠配置开关，必须用log.SetFlags()控制元信息开关，再通过log.SetOutput()接管底层写入逻辑。
常见错误是只调log.SetFlags(0)以为就能“清空格式”，结果发现前缀没了，但时间、路径等仍硬编码在log.Printf内部——其实这些是log.Prefix()之外的额外拼接，真正可控的是log.Ldate、log.Ltime等标志位。
-
log.SetFlags(log.LstdFlags)：默认值，含日期+时间+文件:行号 -
log.SetFlags(log.Ltime | log.Lshortfile)：只留时间+短文件名（如main.go:12） -
log.SetFlags(0)：彻底关闭所有自动前缀，后续全靠你自己拼字符串
用io.Writer封装JSON结构化日志
要输出JSON格式（比如{"level":"error","msg":"timeout","ts":"2024-05-20T10:30:00Z"}），不能依赖log原生能力，得自己实现io.Writer接口，把Write([]byte)重定向为JSON序列化。
关键点在于：日志函数（如log.Printf）最终会把格式化后的字符串传给Writer，但这个字符串已经是完整消息（含空格、换行、前缀），无法拆解出原始level或args。所以必须绕过log包，改用结构化日志库（如zerolog或zap），或自己封装一个Logger类型，暴露Error(msg string, fields map[string]interface{})这类方法。
立即学习“go语言免费学习笔记（深入）”；
- 若坚持用标准
log，只能解析Write接收的字节流，正则提取关键字段——不可靠，且破坏性能 - 推荐用
zerolog.New(os.Stderr).With().Timestamp().Logger()，它默认输出JSON，.With()可注入level、service等固定字段 - 若需兼容老代码，可写一个
CustomLogger，内部用zerolog，对外提供Printf风格方法，但内部转成Info().Msgf()
HTTP中间件中捕获panic并格式化为错误日志
Web框架（如gin或echo）的recover中间件常直接打印panic堆栈到控制台，格式杂乱。要统一成结构化错误日志，得在recover后手动构造日志对象，而不是调log.Print。
典型坑是直接log.Printf("panic: %v\n%v", err, debug.Stack())——这会导致堆栈被当作文本拼进一条日志，丢失结构；更糟的是debug.Stack()返回的是[]byte，直接%v打印可能截断或乱码。
- 先用
recover()拿到interface{}，断言为error或string - 用
debug.Stack()获取完整堆栈，转为string后存入日志字段（如"stack"） - 若用
zerolog，写法类似：logger.Error().Err(err).Str("stack", string(debug.Stack())).Msg("panic recovered") - 注意
debug.Stack()在生产环境可能有性能开销，高并发场景建议关闭或采样
自定义Error类型与日志字段自动注入
Go里error本身不带上下文，但业务错误常需附带request_id、user_id等。如果每次logger.Error().Str("req_id", reqID).Err(err).Msg(...)都手写，极易遗漏。
可行做法是定义带字段的错误类型，例如type AppError struct { Msg string; Code int; Fields map[string]interface{} }，再实现Error() string方法。但日志库不会自动读取Fields——必须显式调用logger.Err(err).Fields(err.(*AppError).Fields)。
- 更稳妥的是用
zerolog.Error().Fields(err.Fields).Msg(err.Msg)，前提是错误类型暴露字段 - 避免在
Error()方法里拼接所有字段（如return fmt.Sprintf("%s [code=%d, req_id=%s]", ...)），这会让日志失去结构化能力 - 若用
fmt.Errorf包装错误，可用errors.As()向下断言到具体类型，再提取字段
真正难的是跨goroutine传递上下文字段。HTTP请求生命周期内能从context.Context取req_id，但后台任务或定时器触发的日志就容易漏——这部分必须在启动goroutine时显式拷贝context.WithValue，否则日志永远缺关键维度。
