Go中日志装饰器本质是签名一致的高阶函数，需保持原函数参数与返回值完全匹配；应使用结构化日志库如Zap/Logrus，避免动态反射和静默recover；性能敏感场景须支持开关与采样。
Go 里用 func 包一层就能记日志，但别直接改原函数签名
Go 没有装饰器语法，所谓“日志装饰器”本质是高阶函数：接收一个函数，返回一个带日志逻辑的新函数。关键不是“怎么写”，而是“怎么不破坏调用方代码”。比如你有个 ProcessUser 函数，外面可能已经到处 ProcessUser(u) 这么调了，就不能让它突然变成 LogWrap(ProcessUser)(u) —— 那等于重构所有调用点。
- 包装函数必须和原函数**完全一致的签名**（参数类型、数量、返回值），否则无法赋值给同类型变量或传给期望该类型的接口
- 用
reflect动态适配所有函数签名太重，也失去编译期检查，不推荐 - 最稳的方式：为每类常用签名单独写一个包装器，比如
LogFunc1（1入1出）、LogFunc2（2入1出）等，靠 IDE 自动补全+复制粘贴也能接受
log.Printf 不够用，得用 log.WithFields 或结构化日志库
只在入口打 log.Printf("calling ProcessUser %v", u.ID) 很容易淹没在日志海里，而且没法按字段过滤。真实服务里需要知道谁调的、耗时多少、是否出错、上下文 ID 是什么——这些光靠字符串拼接搞不定。
- 如果用标准库，至少把函数名、开始时间、参数快照存进
map[string]interface{}，再用fmt.Printf手动格式化，但很快会失控 - 更现实的选择是引入
github.com/sirupsen/logrus或go.uber.org/zap，它们的WithField/With方法能自然嵌套上下文 - 注意：
zap.Logger是非线程安全的，包装器里别反复logger.With(...)后又丢弃，应该在调用前一次性构造好子 logger
别在装饰器里 recover panic，除非你明确要吞掉它
有人会在日志包装器里加 defer func() { if r := recover(); r != nil { log.Error("panic: ", r) } }()，以为这样“更健壮”。结果是 panic 被静默吃掉，上层根本收不到错误，HTTP handler 返回 200 却没干成事，排查时一头雾水。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 日志装饰器只负责记录“发生了什么”，不负责“怎么兜底”
- recover 应该出现在真正能处理错误的位置，比如 HTTP 中间件、goroutine 启动处，而不是每个业务函数包装器里
- 如果真要记录 panic，至少把原始 stack trace 打出来：
debug.PrintStack()，不然recover()返回的interface{}几乎没信息量
性能敏感场景下，日志装饰器要支持开关和采样
高频调用函数（比如每秒几千次的 ValidateToken）如果每次进都打日志，I/O 和序列化开销会直接拖垮吞吐。上线后才发现 QPS 掉了一半，就因为加了个“简单”的日志包装。
立即学习“go语言免费学习笔记（深入）”；
- 用包级变量或配置项控制是否启用日志，比如
var EnableLog bool = false，编译期可条件编译（//go:build log）更彻底 - 对非错误路径做采样，例如只记录 0.1% 的成功调用：
if rand.Float64() - 避免在日志里调用
time.Now().String()或fmt.Sprintf，优先用log.WithField("took_ms", dur.Milliseconds())这类延迟格式化方式
真正麻烦的从来不是“怎么写个日志包装器”，而是想清楚：哪些函数值得被包、日志字段要不要透传 context、失败时要不要自动上报 metric、以及——有没有人会半夜因为这条日志查错查到崩溃。
