当前位置:首页 > 文章列表 > Golang > Go教程 > Go slog 生产实践:日志别只会打印 error,要能帮你排障

Go slog 生产实践:日志别只会打印 error,要能帮你排障

来源:Go 官方博客与近期 slog 生产实践资料参考,17golang 原创解读 2026-06-01 19:46:42 0浏览 收藏

很多 Go 服务不是没有日志,而是日志没法用:一堆 log.Println(err),线上真出事时,你搜不到 request_id,看不到用户、订单、下游、耗时,也不知道这条 error 到底该告警还是只是业务拒绝。Go 标准库里的 log/slog,真正值得用的地方不是“换个 logger”,而是让日志变成可查询、可聚合、可关联的结构化事件。

这篇按我做线上服务的习惯聊,不堆 API 清单。我们重点看:字段怎么设计,context 里放什么,错误怎么打,敏感信息怎么脱敏,最后怎么让日志和 trace、metrics 对得上。

Go slog 生产结构化日志思维导图
思维导图:生产级 slog 不是把文本换成 JSON,而是把日志字段、上下文、错误级别和观测链路统一起来。

先想清楚:日志是给机器查的,不只是给人看的

普通文本日志适合本地调试,但生产环境里你更常做的是搜索和聚合:某个用户最近 10 分钟发生了什么、某个接口 P99 升高时有没有下游错误、某类 error 一小时出现了多少次。

所以字段名要稳定。不要今天叫 uid,明天叫 userId,后天又叫 user_id。日志系统最怕字段随心情漂移,最后查询语句比业务代码还难维护。

我的基础字段习惯

入口层我通常会固定这些字段:service、env、request_id、trace_id、method、path、status、cost_ms。业务字段另算,比如 user_id、order_id、tenant_id。

字段不是越多越好。高基数字段比如完整 URL、原始请求体、超长 SQL,不应该随便打进每条日志。否则检索成本、存储成本、隐私风险都会上来。

Go slog 生产日志落地流程图
流程图:从入口统一注入上下文,到业务层补关键字段,再到边界层分类打日志,最后进入检索和告警。

入口层先做一件事:准备好带上下文的 logger

我不喜欢在每个函数里重新拼 request_id。更舒服的做法是在入口处构造一个带公共字段的 logger,然后往下传,或者从 context 里取。

func withLogger(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        rid := requestID(r)
        traceID := traceIDFromContext(r.Context())

        logger := slog.Default().With(
            "request_id", rid,
            "trace_id", traceID,
            "method", r.Method,
            "path", r.URL.Path,
        )

        ctx := context.WithValue(r.Context(), loggerKey{}, logger)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

这里要克制一点:context 里可以放 request-scoped logger,但不要把一堆业务参数都塞进去。业务参数还是通过函数参数传,日志字段只保留排障需要的上下文。

错误日志:不要每层都打,也不要只打一层 failed

Go 代码里最容易把日志打乱的地方就是 error。底层一失败就打一条,service 再打一条,handler 又打一条,最后同一个错误刷三遍,告警看起来像三次事故。

我的规则是:中间层负责返回带上下文的 error,边界层负责决定日志级别和字段。比如 handler、consumer、cron job 这些地方才是真正适合落日志的位置。

func (h *Handler) GetOrder(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    orderID := r.PathValue("id")

    order, err := h.svc.GetOrder(ctx, orderID)
    if err != nil {
        logger := Logger(ctx).With("order_id", orderID)
        if errors.Is(err, ErrOrderNotFound) {
            logger.WarnContext(ctx, "order not found", "err", err)
            http.Error(w, "not found", http.StatusNotFound)
            return
        }
        logger.ErrorContext(ctx, "get order failed", "err", err)
        http.Error(w, "internal error", http.StatusInternalServerError)
        return
    }

    _ = json.NewEncoder(w).Encode(order)
}
Go slog 错误日志案例图
案例图:左边是重复又没字段的 error 日志,右边是带 request_id、order_id、trace_id 和明确级别的生产日志。

脱敏要在 handler 里形成制度

日志最怕“临时加一个字段看看”,然后把手机号、身份证、token、cookie、银行卡号打进生产。slog 的好处是你可以通过 LogValuer 或自定义 Handler 统一处理敏感字段。

我建议至少把这些字段列进禁止清单:password、token、authorization、cookie、phone、id_card。能打 hash 就别打原文,能打后四位就别打完整值。

日志级别别当装饰

Info 是关键业务事件,Warn 是可预期但需要关注的异常,Error 是请求失败、任务失败、依赖不可用这类需要排查的问题。不要所有失败都 Error,也不要所有事情都 Info。

一个常见例子:用户输入错误、订单不存在、权限不足,很多时候是业务可预期结果,打 Warn 就够了。数据库超时、Redis 故障、下游 500,才应该进入 Error 和告警候选。

和 trace、metrics 对齐才真的好用

单独一条日志价值有限。生产排障更常见的路径是:metrics 发现某接口错误率升高,trace 找到慢链路,日志通过 trace_id 或 request_id 查到具体错误上下文。三者能对齐,排障速度才会明显提升。

所以 request_id、trace_id 不要只出现在网关日志里,应用日志也要带上。否则你会在不同系统之间手工拼时间戳,这事凌晨两点做起来很痛苦。

我的 slog review 清单

  • 字段命名是否稳定,比如统一使用 request_id、trace_id、user_id?
  • 入口层是否统一注入公共字段,而不是每个业务函数各写各的?
  • 错误是否只在边界层落一次日志,中间层只补上下文返回?
  • 敏感字段是否统一脱敏,token、cookie、手机号有没有直接输出?
  • 日志级别是否有语义,Warn 和 Error 有没有明确边界?
  • 高基数字段和大字段有没有控制,避免日志成本失控?
  • 日志里是否能和 trace、metrics 对齐,至少有 request_id 或 trace_id?

最后聊两句

slog 不是为了让日志看起来更现代,而是为了让线上排障少一点猜谜。真正有用的日志,应该能在事故时回答三个问题:这是谁的请求,在哪个环节失败,下一步该查哪个依赖。

我的建议是先别急着换一堆花哨封装。把字段名、错误落点、脱敏规则、trace_id 这几件基础事做好,slog 就已经能让你的 Go 服务排障体验上一个台阶。

版本声明
本文转载于:Go 官方博客与近期 slog 生产实践资料参考,17golang 原创解读 如有侵犯,请联系study_golang@163.com删除
Go testing/synctest 实战:别再用 time.Sleep 赌并发测试会过Go testing/synctest 实战:别再用 time.Sleep 赌并发测试会过
上一篇
Go testing/synctest 实战:别再用 time.Sleep 赌并发测试会过
Go JSON v2 实战:别急着替换 encoding/json,先搞懂这些变化
下一篇
Go JSON v2 实战:别急着替换 encoding/json,先搞懂这些变化
查看更多
最新文章
查看更多
课程推荐
  • 前端进阶之JavaScript设计模式
    前端进阶之JavaScript设计模式
    设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
    543次学习
  • GO语言核心编程课程
    GO语言核心编程课程
    本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
    516次学习
  • 简单聊聊mysql8与网络通信
    简单聊聊mysql8与网络通信
    如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
    500次学习
  • JavaScript正则表达式基础与实战
    JavaScript正则表达式基础与实战
    在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
    487次学习
  • 从零制作响应式网站—Grid布局
    从零制作响应式网站—Grid布局
    本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
    485次学习
查看更多
AI推荐
  • PubMedQA数据集详解:生物医学问答基准、功能与应用指南
    PubMedQA
    深入了解PubMedQA生物医学问答数据集,涵盖其核心功能、使用方法及在临床决策、药物研发等场景的应用,助力提升NLP模型性能。
    490次使用
  • H2O EvalGPT:开源LLM大模型评估与排行榜工具
    H2O EvalGPT
    H2O EvalGPT是H2O.ai推出的开源LLM评估平台,提供详细的大模型性能排行榜、行业特定基准测试及A/B测试功能,助您快速选择最适合项目的高性能大语言模型。
    547次使用
  • LMArena是什么?伯克利AI模型评估平台使用指南与功能解析
    LMArena
    LMArena是加州大学伯克利分校推出的AI模型匿名评测平台。通过盲测投票机制,用户可对比不同大模型回答并生成实时排行榜,助力开发者优化模型及用户选择最佳AI工具。
    572次使用
  • 斯坦福HELM:大语言模型Holistic Evaluation整体评估框架详解
    HELM
    深入了解斯坦福推出的HELM(Holistic Evaluation of Language Models)大模型评测体系。本文解析其核心功能、安装配置步骤及应用场景,涵盖准确性、公平性、鲁棒性等多维度指标,助力开发者全面优化语言模型性能。
    526次使用
  • MMBench详解:多模态大模型基准测试、功能特点与使用指南
    MMBench
    MMBench是由上海人工智能实验室等机构联合推出的多模态基准测试平台,提供细粒度能力评估、大规模数据集及VLMEvalKit工具。本文详细介绍其核心功能、安装使用方法及应用场景,助力开发者全面评估多模态模型性能。
    339次使用