当前位置:首页 > 文章列表 > 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。日志系统最怕字段随心情漂移,最后查询语句比业务代码还难维护。

我的基础字段习惯

入口层我通常会固定这些字段:serviceenvrequest_idtrace_idmethodpathstatuscost_ms。业务字段另算,比如 user_idorder_idtenant_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 统一处理敏感字段。

我建议至少把这些字段列进禁止清单:passwordtokenauthorizationcookiephoneid_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_idtrace_iduser_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推荐
  • ChatExcel酷表:告别Excel难题,北大团队AI助手助您轻松处理数据
    ChatExcel酷表
    ChatExcel酷表是由北京大学团队打造的Excel聊天机器人,用自然语言操控表格,简化数据处理,告别繁琐操作,提升工作效率!适用于学生、上班族及政府人员。
    5892次使用
  • Any绘本:开源免费AI绘本创作工具深度解析
    Any绘本
    探索Any绘本(anypicturebook.com/zh),一款开源免费的AI绘本创作工具,基于Google Gemini与Flux AI模型,让您轻松创作个性化绘本。适用于家庭、教育、创作等多种场景,零门槛,高自由度,技术透明,本地可控。
    6326次使用
  • 可赞AI:AI驱动办公可视化智能工具,一键高效生成文档图表脑图
    可赞AI
    可赞AI,AI驱动的办公可视化智能工具,助您轻松实现文本与可视化元素高效转化。无论是智能文档生成、多格式文本解析,还是一键生成专业图表、脑图、知识卡片,可赞AI都能让信息处理更清晰高效。覆盖数据汇报、会议纪要、内容营销等全场景,大幅提升办公效率,降低专业门槛,是您提升工作效率的得力助手。
    6137次使用
  • 星月写作:AI网文创作神器,助力爆款小说速成
    星月写作
    星月写作是国内首款聚焦中文网络小说创作的AI辅助工具,解决网文作者从构思到变现的全流程痛点。AI扫榜、专属模板、全链路适配,助力新人快速上手,资深作者效率倍增。
    8107次使用
  • MagicLight.ai:叙事驱动AI动画视频创作平台 | 高效生成专业级故事动画
    MagicLight
    MagicLight.ai是全球首款叙事驱动型AI动画视频创作平台,专注于解决从故事想法到完整动画的全流程痛点。它通过自研AI模型,保障角色、风格、场景高度一致性,让零动画经验者也能高效产出专业级叙事内容。广泛适用于独立创作者、动画工作室、教育机构及企业营销,助您轻松实现创意落地与商业化。
    6589次使用
微信登录更方便
  • 密码登录
  • 注册账号
登录即同意 用户协议隐私政策
返回登录
  • 重置密码