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