Logrus钩子是日志“拦截+增强+路由”的控制点，必须实现logrus.Hook接口（含Fired和Levels方法），而非直接传函数；常见错误包括误用匿名函数、混淆非官方FieldHook、在钩子中无效修改entry，多目标应分设独立Hook实例。
Logrus 的钩子（Hook）不是日志“分发”的搬运工，而是日志“拦截+增强+路由”的控制点；直接往 logrus.Hooks.Add() 里塞函数不会生效，必须实现 logrus.Hook 接口。
为什么 logrus.Hooks.Add() 接收的是接口，不是函数？
Logrus 设计上要求钩子能响应多个生命周期事件（Fired、Levels），而不仅仅是“日志来了就处理”。比如你希望只在 Error 级别触发告警，同时又想在 Info 级别写入本地文件——单个函数无法声明自己支持哪些级别。
所以你必须定义一个结构体，实现这两个方法：
-
Fired(entry *logrus.Entry) error：真正干活的地方，比如发 HTTP、写文件、打标记 -
Levels() []logrus.Level：明确告诉 Logrus “我只处理哪些级别”，例如[]logrus.Level{logrus.ErrorLevel, logrus.FatalLevel}
常见错误是写了个闭包或匿名函数传给 Add()，结果日志照常输出但钩子完全没触发——因为类型不匹配，Logrus 直接跳过。
立即学习“go语言免费学习笔记（深入）”；
logrus.FieldHook 是假的，别被名字骗了
社区里流传的 logrus.FieldHook（比如加 timestamp 字段）不是 Logrus 官方内置类型，而是某篇旧教程自定义的结构体。Logrus 本身没有这个类型。
正确做法是用 entry.Data["timestamp"] = time.Now().UTC().Format(...) 在钩子的 Fired 方法里手动注入字段。或者更轻量：直接用 WithField 或 WithFields 在打日志时带上，根本不需要钩子。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
容易踩的坑：
- 在钩子里反复调用
entry.WithField并试图返回新 entry ——entry是值拷贝，改了也没用 - 以为钩子能修改日志消息文本（
entry.Message）并影响最终输出 —— 多数 formatter 读的是原始entry.Message，改了字段不等于改了 message
多目标分发：用多个 Hook，而不是一个 Hook 里写一堆 if
想同时把 Error 日志发 Slack、写本地文件、推 Kafka？别在一个钩子里堆逻辑。每个目标单独建一个 Hook 实例，各自声明支持的 Levels()，然后都 Add() 进去。
这样做的好处：
- 职责清晰：SlackHook 只管网络请求，FileHook 只管
os.WriteFile - 可开关：临时禁用 Kafka 上报？删掉那一行
Add()就行，不影响其他 - 易测试：每个 Hook 可独立 mock 依赖（比如把
http.Client替换为httptest.Server）
性能提示：如果某个 Hook 操作耗时（如远程 API 调用），务必启动 goroutine 异步执行，并注意错误是否需反馈 —— Logrus 默认同步调用所有 Hook，卡住主线程。
语言学习中别过早抽象钩子
初学 Go 时，看到“钩子”容易联想到“高阶抽象”“插件机制”，于是急着封装通用 Hook 基类、反射加载、配置驱动……实际项目里 90% 的钩子就是 10 行以内的结构体。
真正复杂的是日志语义，不是钩子语法。比如：
- 什么字段该进日志？
user_id必须有，ip在调试时才有用 - 哪条 Error 真该告警？不是所有
Error()都要发钉钉，得结合上下文字段（如"retry_count": 5）判断
钩子只是执行器。先理清“日志要表达什么”，再决定“用哪个 Hook 做什么”，而不是反过来。
