Go标准库log包不支持结构化日志，反射虽可实现通用封装但需谨慎：须检查字段可导出性、避免无条件热路径反射、优先类型断言分流、缓存反射结果、禁用低级别日志的反射逻辑。
Go 语言标准库的 log 包本身不支持字段化、结构化日志，而反射是实现「通用日志封装」最直接的手段之一——但它不是万能解法，用不好反而引入性能损耗和 panic 风险。
用 reflect.ValueOf 提取结构体字段值时，必须检查可导出性
Go 反射无法读取非导出（小写开头）字段，直接调用 .Interface() 或 .String() 会 panic。常见错误现象是日志函数接收任意 interface{} 后对结构体做反射遍历，结果在某个私有字段上崩溃。
- 始终先用
v.CanInterface()判断是否可访问 - 用
v.Kind() == reflect.Struct+v.Type().Field(i).PkgPath != ""检查字段是否导出（PkgPath非空表示未导出） - 不要依赖
v.String()输出字段值——它可能返回空字符串或 panic；应根据v.Kind()分支处理：如reflect.String用v.String()，reflect.Int用v.Int()，指针需先v.Elem()
避免在日志热路径中无条件触发反射
每次调用日志函数都做完整结构体反射，会导致 GC 压力上升、CPU 占用翻倍。实际场景中，90% 的日志参数是简单类型（string、int、error），没必要走反射分支。
- 优先用类型断言分流：
if s, ok := v.(string); ok { ... }，再 fallback 到反射 - 对已知结构体类型（如
http.Request、自定义User）做缓存：用reflect.TypeOf(v)作 key，预计算字段名和 getter 函数，避免重复reflect.ValueOf和遍历 - 禁用日志级别低于
Debug时的反射逻辑——例如if logLevel ，防止低优先级日志拖慢主流程
log/slog Go 1.21+ 原生支持结构化日志，反射封装应让位于原生能力
Go 1.21 引入的 slog 已内置 slog.Any("key", value)，对结构体自动展开（内部仍用反射，但经深度优化且可控）。强行自己封装反射日志，反而绕过其缓存、惰性求值、属性过滤等机制。
立即学习“go语言免费学习笔记（深入）”；
- 直接用
slog.With(slog.Group("req", slog.String("method", r.Method), slog.String("path", r.URL.Path)))替代手写结构体遍历 - 若需自定义格式（如加 trace_id），实现
slog.Handler接口，而非重写日志参数解析逻辑 - 注意
slog.Any对循环引用、大 map/slice 默认不深拷贝——若需安全序列化，应提前用json.Marshal或专用 sanitizer 处理，而不是在反射里硬扛
真正需要反射的场景其实很窄：比如统一审计日志需记录任意业务对象变更前后状态，且无法预知类型。这种情况下，反射不是首选方案，而是兜底手段——优先约定接口（如 Loggable）、用代码生成（stringer 类工具）、或强制传入 map[string]any。硬啃反射，最后往往卡在 nil 指针、嵌套 interface{}、time.Time 格式不一致这些细节上。
