Logrus本身不支持标准输出的业务维度过滤，仅提供级别控制；需通过自定义Hook在Fire()中基于path、service_name等字段判断并返回error实现精准过滤，且Levels()须显式声明监听级别。
Logrus 本身不支持标准输出的“过滤”功能，它只负责格式化和写入；真正的过滤逻辑必须由你手动实现——要么在日志字段上做条件判断，要么用 Hook 拦截并丢弃不需要的日志。
为什么直接用 logrus.SetLevel() 不够用
微服务里常需按服务名、HTTP 路径、错误码甚至 trace ID 过滤日志，而 logrus.SetLevel() 只能控制 Debug/Info/Warn 等级别，对业务维度完全无感。比如你只想看 /api/v2/orders 的请求日志，或屏蔽所有 healthz 的 Info 日志——这必须自己加逻辑。
-
logrus.SetLevel()是全局级别开关，无法区分来源 - 所有日志仍会经过 formatter 和 writer，只是 level 不匹配时跳过输出——但 hook 仍会被触发
- 若用了
logrus.WithField()带上path或service，就得靠自定义 hook 做字段级过滤
用自定义 Hook 实现路径/标签过滤
Logrus 的 Hook 接口允许你在日志写入前介入。一个轻量过滤 hook 只需实现 Fire() 方法，内部判断是否放行：
type FilterHook struct {
AllowPaths []string
RejectKeys map[string]struct{}
}
func (h *FilterHook) Fire(entry *logrus.Entry) error {
// 按 HTTP 路径过滤（假设 entry.Data 里有 "path" 字段）
if path, ok := entry.Data["path"].(string); ok {
for _, allow := range h.AllowPaths {
if strings.HasPrefix(path, allow) {
return nil // 放行
}
}
return errors.New("filtered by path") // 不匹配就返回 error，logrus 会跳过写入
}
// 按键名黑名单过滤（如屏蔽 "sql"、"debug_data"）
for key := range h.RejectKeys {
if _, exists := entry.Data[key]; exists {
return errors.New("filtered by key")
}
}
return nil
}
func (h *FilterHook) Levels() []logrus.Level {
return logrus.AllLevels // 对所有级别生效
}
- 返回非
nilerror 表示拒绝该条日志，Logrus 就不会调用 writer - 注意：hook 的
Levels()必须显式返回要监听的级别，不能留空 - 避免在
Fire()里做耗时操作（如网络请求、磁盘 IO），否则拖慢整个日志链路
与 Zap 对比：Logrus 在微服务中过滤的代价在哪
Logrus 的 hook 机制是同步阻塞的，每条日志都会串行走过所有注册的 hook。当你的微服务 QPS 上千、又挂了多个 hook（比如 Sentry + 文件轮转 + 过滤），CPU 和延迟敏感度会明显升高。Zap 的 Core 虽也支持拦截，但它是基于接口组合 + 零分配设计，实测吞吐高 3–5 倍。
立即学习“go语言免费学习笔记（深入）”；
- Logrus 过滤逻辑写在 hook 里，意味着每次日志都要做字符串判断、map 查找、interface{} 类型断言
- 如果用
entry.Logger.WithField("trace_id", tid)大量携带上下文，过滤 hook 里反复取entry.Data["trace_id"]会触发 map copy 开销 - 生产环境建议把高频过滤条件（如健康检查路径）做成前缀树或静态 map 查表，别用
strings.Contains()
真正难的不是写个过滤 hook，而是确认哪些字段稳定可依赖、哪些字段可能为空或类型错乱——比如 entry.Data["status_code"] 有时是 int，有时是 string，没做类型保护就会 panic。微服务日志统一治理，字段契约比过滤逻辑更关键。
