Debug | Tony Bai

标签 Debug 下的文章

slog正式版来了：Go日志记录新选择！

九月 1, 2023
0 条评论

本文永久链接 – https://tonybai.com/2023/09/01/slog-a-new-choice-for-logging-in-go

在大约一年前，我就写下了《slog：Go官方版结构化日志包》一文，文中介绍了Go团队正在设计并计划在下一个Go版本中落地的Go官方结构化日志包：slog。但slog并未如预期在Go 1.20版本中落地，而是在golang.org/x/exp/slog下面给出了slog的初始实现供社区体验。

时光飞逝，slog在golang.org/x/exp/slog下经历了1年多时间的改善和演进，终于在最近发布的Go 1.21版本中以log/slog的包导入路径正式加入Go标准库。

正式版的slog在结构上并未作较大变化，依旧是分为前端和后端，因此讲exp/slog时的那幅图依然适用：

不过，正式版的slog与当初那篇文章中的exp/slog在一些类型与API上已有不同。在这篇文章中，我就来简要说明一下。我这里讲述的思路大致是将《slog：Go官方版结构化日志包》一文中的例子用log/slog改造一遍，这个过程可以让我们看到正式版log/slog与exp/slog的差异。

1. slog快速入门

1.1 slog的”hello, world”

如果仅是想以最快速的方式开始使用slog，那么下面可以算是slog的”hello, world”版本：

//slog-examples-go121/demo0/main.go

package main

import (
    "log/slog"
)

func main() {
    slog.Info("my first slog msg", "greeting", "hello, slog")
}

运行这段程序，会得到下面输出：

$go run main.go
2023/08/29 05:01:36 INFO my first slog msg greeting="hello, slog"

1.2 TextHandler和JSONHandler

默认情况下，slog输出的格式仅是普通text格式，而并非JSON格式，也不是以key=value形式呈现的文本。

slog提供了以JSON格式输出的JSONHandler和以key=value形式呈现的文本形式的TextHandler。不过要使用这两种Handler进行日志输出，我们需要显式创建它们：

//slog-examples-go121/demo1/main.go

h := slog.NewTextHandler(os.Stderr, nil)
l := slog.New(h)
l.Info("greeting", "name", "tony")
l.Error("oops", "err", net.ErrClosed, "status", 500)

h1 := slog.NewJSONHandler(os.Stderr, nil)
l1 := slog.New(h1)
l1.Info("greeting", "name", "tony")
l1.Error("oops", "err", net.ErrClosed, "status", 500)

注：相对于exp/slog，正式版的log/slog的NewTextHandler和NewJSONHandler增加了一个新的opts *HandlerOptions参数。

上述代码分别创建了一个使用TextHandler的slog.Logger实例以及一个使用JSONHandler的slog.Logger实例，执行这段代码后将输出如下日志：

$go run main.go
time=2023-08-29T05:34:27.370+08:00 level=INFO msg=greeting name=tony
time=2023-08-29T05:34:27.370+08:00 level=ERROR msg=oops err="use of closed network connection" status=500
{"time":"2023-08-29T05:34:27.370306+08:00","level":"INFO","msg":"greeting","name":"tony"}
{"time":"2023-08-29T05:34:27.370315+08:00","level":"ERROR","msg":"oops","err":"use of closed network connection","status":500}

如果觉得每次还得使用l或l1来调用Info、Error等输出日志的函数不便利，可以将l或l1设置为Default Logger，这样无论在任何包内都可以直接通过slog包级函数，如Info、Error等直接输出日志：

//slog-examples-go121/demo1/main.go

time=2023-08-29T05:40:08.503+08:00 level=INFO msg="textHandler after setDefault" name=tony age=30
{"time":"2023-08-29T05:40:08.503672+08:00","level":"INFO","msg":"jsonHandler after setDefault","name":"tony","age":30}

注：相对于exp/slog，正式版的log/slog提供了带有Context的Info、Error日志输出函数：DebugContext、InfoContext、ErrorContext等。

1.3 HandlerOption

通过在创建Handler时传入自定义的HandlerOption，我们可以设置Logger的日志级别和是否输出Source，比如下面示例：

//slog-examples-go121/demo2/main.go

opts := slog.HandlerOptions{
AddSource: true,
Level:     slog.LevelError,
}

slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stderr, &opts)))
slog.Info("open file for reading", "name", "foo.txt", "path", "/home/tonybai/demo/foo.txt")
slog.Error("open file error", "err", os.ErrNotExist, "status", 2)

上述代码通过HandlerOption设置了Handler仅输出Error级别日志，并在输出的日志中带上Source信息，运行这段程序，会得到下面输出：

$go run main.go
{"time":"2023-08-29T05:18:18.068213+08:00","level":"ERROR","source":{"function":"main.main","file":"/Users/tonybai/Go/src/github.com/bigwhite/experiments/slog-examples-go121/demo2/main.go","line":17},"msg":"open file error","err":"file does not exist","status":2}

我们看到通过Info函数输出的日志并没有被仅处理Error级别的Handler输出到console上。另外在输出的日志中，我们看到了source这个key，以及它的值，即输出日志的那行代码在源代码文件中位置。

1.4 属性字段

我们日常输出的日志都有一些共同的字段，比如上面的level、time，这些字段被称为属性。slog支持带有属性(attribute)的日志输出，slog内置了若干属性，如下面代码所示：

// log/slog/handler.go

// Keys for "built-in" attributes.
const (
    // TimeKey is the key used by the built-in handlers for the time
    // when the log method is called. The associated Value is a [time.Time].
    TimeKey = "time"
    // LevelKey is the key used by the built-in handlers for the level
    // of the log call. The associated value is a [Level].
    LevelKey = "level"
    // MessageKey is the key used by the built-in handlers for the
    // message of the log call. The associated value is a string.
    MessageKey = "msg"
    // SourceKey is the key used by the built-in handlers for the source file
    // and line of the log call. The associated value is a string.
    SourceKey = "source"
)

当然slog也支持自定义属性：

//slog-examples-go121/demo2/main.go

l := slog.Default().With("attr1", "attr1_value", "attr2", "attr2_value")
l.Error("connect server error", "err", net.ErrClosed, "status", 500)
l.Error("close conn error", "err", net.ErrClosed, "status", 501)

在上面的代码中，我们定义了两个属性：attr1和attr2，以及它们的值，这样当我们用带有这两个属性的Logger输出日志时，每行日志都会包含这两个属性：

{"time":"2023-08-29T05:28:39.322014+08:00","level":"ERROR","source":{"function":"main.main","file":"/Users/tonybai/Go/src/github.com/bigwhite/experiments/slog-examples-go121/demo2/main.go","line":23},"msg":"connect server error","attr1":"attr1_value","attr2":"attr2_value","err":"use of closed network connection","status":500}
{"time":"2023-08-29T05:28:39.322028+08:00","level":"ERROR","source":{"function":"main.main","file":"/Users/tonybai/Go/src/github.com/bigwhite/experiments/slog-examples-go121/demo2/main.go","line":24},"msg":"close conn error","attr1":"attr1_value","attr2":"attr2_value","err":"use of closed network connection","status":501}

当然你也可以通过slog.LogAttrs做“一次性”的属性输出：

//slog-examples-go121/demo2/main.go

l.LogAttrs(context.Background(), slog.LevelError, "log with attribute once", slog.String("attr3", "attr3_value"))
l.Error("reconnect error", "err", net.ErrClosed, "status", 502)

这两行输出如下日志：

{"time":"2023-08-29T05:32:00.419772+08:00","level":"ERROR","source":{"function":"main.main","file":"/Users/tonybai/Go/src/github.com/bigwhite/experiments/slog-examples-go121/demo2/main.go","line":26},"msg":"log with attribute once","attr1":"attr1_value","attr2":"attr2_value","attr3":"attr3_value"}
{"time":"2023-08-29T05:32:00.419778+08:00","level":"ERROR","source":{"function":"main.main","file":"/Users/tonybai/Go/src/github.com/bigwhite/experiments/slog-examples-go121/demo2/main.go","line":27},"msg":"reconnect error","attr1":"attr1_value","attr2":"attr2_value","err":"use of closed network connection","status":502}

我们看到通过LogAttrs输出的attr3属性仅出现一次。

注：相对于exp/slog，正式版的log/slog提供的LogAttrs方法多了一个context.Context参数。

1.5 Group形式的日志输出

slog支持group形式的日志输出，这点保持了与exp/slog的一致。下面是一个输出group log的例子：

//slog-examples-go121/demo2/main.go

gl := l.WithGroup("response")
gl.Error("http post response", "code", 403, "status", "server not response", "server", "10.10.121.88")

我们先创建一个名为“response”的group logger，然后调用Error输出日志。Error会将所有attribute之外的字段放入response这个group中呈现，我们看一下运行结果：

{"time":"2023-08-29T12:54:07.623002+08:00","level":"ERROR","source":{"function":"main.main","file":"/Users/tonybai/Go/src/github.com/bigwhite/experiments/slog-examples-go121/demo2/main.go","line":30},"msg":"http post response","attr1":"attr1_value","attr2":"attr2_value","response":{"code":403,"status":"server not response","server":"10.10.121.88"}}

2. 动态调整日志级别

exp/slog使用slog.AtomicLevel实现Logger级别的动态调整。在正式版slog中，我们则使用slog.LevelVar来实现Logger日志级别的动态调整，使用方法差不多，看下面这个例子：

// slog-examples-go121-demo3/main.go

func main() {
    var lvl slog.LevelVar
    lvl.Set(slog.LevelDebug)
    opts := slog.HandlerOptions{
        Level: &lvl,
    }
    slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stderr, &opts)))

    slog.Info("before resetting log level:")

    slog.Info("greeting", "name", "tony")
    slog.Error("oops", "err", net.ErrClosed, "status", 500)
    slog.LogAttrs(context.Background(), slog.LevelError, "oops",
        slog.Int("status", 500), slog.Any("err", net.ErrClosed))

    slog.Info("after resetting log level to error level:")
    lvl.Set(slog.LevelError)
    slog.Info("greeting", "name", "tony")
    slog.Error("oops", "err", net.ErrClosed, "status", 500)
    slog.LogAttrs(context.Background(), slog.LevelError, "oops",
        slog.Int("status", 500), slog.Any("err", net.ErrClosed))

}

结合LevelVar和HandlerOption，我们实现了Logger日志级别的动态调整，这里是由LevelDebug调整为LevelError。上面示例的输出结果如下：

{"time":"2023-08-29T06:15:26.103022+08:00","level":"INFO","msg":"before resetting log level:"}
{"time":"2023-08-29T06:15:26.103197+08:00","level":"INFO","msg":"greeting","name":"tony"}
{"time":"2023-08-29T06:15:26.103203+08:00","level":"ERROR","msg":"oops","err":"use of closed network connection","status":500}
{"time":"2023-08-29T06:15:26.103222+08:00","level":"ERROR","msg":"oops","status":500,"err":"use of closed network connection"}
{"time":"2023-08-29T06:15:26.103226+08:00","level":"INFO","msg":"after resetting log level to error level:"}
{"time":"2023-08-29T06:15:26.103232+08:00","level":"ERROR","msg":"oops","err":"use of closed network connection","status":500}
{"time":"2023-08-29T06:15:26.103236+08:00","level":"ERROR","msg":"oops","status":500,"err":"use of closed network connection"}

我们看到，动态调整到LevelError后，Info函数打印的日志将不再输出到console了。

3. 自定义后端Handler

在《slog：Go官方版结构化日志包》一文中，我们就举例说明了如何自定义一个后端Handler，正式版slog在自定义Handler这方面变化不大，都是通过实现slog.Handler接口的方式达成的。大家可自行查看slog-examples-go121/demo4中的代码，这里就不赘述了。

此外，log/slog的作者Jonathan Amsterdam还提供了一篇“slog自定义handler指南”供大家参考。

4. 验证handler

Go 1.21正式版提供了一个testing/slogtest包可以用来辅助测试自定义后端Handler，我们就以slog-examples-go121/demo4中自定义的ChanHandler为例，用slogtest包对其进行一下测试：

// slog-examples-go121/demo4/handler_test.go

func TestChanHandlerParsing(t *testing.T) {
    var ch = make(chan []byte, 100)
    h := NewChanHandler(ch)

    results := func() []map[string]any {
        var ms []map[string]any
        ticker := time.NewTicker(time.Second)
    loop:
        for {
            select {
            case line := <-ch:
                if len(line) == 0 {
                    break
                }
                var m map[string]any
                if err := json.Unmarshal(line, &m); err != nil {
                    t.Fatal(err)
                }
                ms = append(ms, m)
            case <-ticker.C:
                break loop
            }
        }
        return ms
    }
    err := slogtest.TestHandler(h, results)
    if err != nil {
        log.Fatal(err)
    }
}

slogtest仅提供一个导出函数TestHandler，它会自动基于你提供的Handler创建Logger并向Logger写入一些日志，然后通过传入的results函数对写入的日志进行格式验证，主要是json反序列化，如果成功，会记录在map[string]any类型的切片中。最后TestHandler会比对写入日志条数与反序列化成功的条数，如果一致，说明测试ok，反之则测试失败。

注：基于这个TestHandler，还真测试出原ChanHandler的一个问题，已经fix。

5. 性能tips

按官方benchmark结果，log/slog的性能要高于Go社区常用的结构化日志包，比如zap等。

即便如此，log在go应用中带来的延迟依旧不可忽视。slog的proposal design中给出了一些关于性能的考量和tip，大家可以在日后使用slog时借鉴：

使用Logger.With避免重复格式化公共属性字段，这使得处理程序可以缓存格式化结果。
将昂贵的计算推迟到日志输出时再进行，例如传递指针而不是格式化后的字符串。这可以避免在禁用的日志行上进行不必要的工作。
对于昂贵的值，可以实现LogValuer接口，这样在输出时可以进行lazy加载计算。

// log/slog/value.go

// A LogValuer is any Go value that can convert itself into a Value for logging.
//
// This mechanism may be used to defer expensive operations until they are
// needed, or to expand a single value into a sequence of components.
type LogValuer interface {
    LogValue() Value
}

最后，内置的Handler已经处理了原子写入的加锁。自定义Handler应该实现自己的加锁。

6. 小结

总体来说，slog正式版与之前实现相比，接口变化不大，功能也基本保持不变，但代码质量、性能、文档等有较大改进，符合预期。

slog填补了Go标准库在结构化日志支持上的短板，提供了简洁、易用、易扩展的API。相信随着slog的推广，可以逐步统一Go社区中的日志实践，也让更多人受益。

个人建议：新项目如果没有使用第三方日志包，可以直接采用slog，无需再考虑zap、zerolog等第三方选择。对于没有升级到Go 1.21版本的新项目，也可以使用exp/slog，目前exp/slog也已经与log/slog保持了同步。

本文涉及的示例代码可以在这里下载。

7. 参考资料

Proposal: Structured Logging – https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md
slog包手册 – https://pkg.go.dev/log/slog
Structured Logging with slog – https://go.dev/blog/slog
A Guide to Writing slog Handlers – https://github.com/golang/example/blob/master/slog-handler-guide/README.md

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

微博(暂不可用)：https://weibo.com/bigwhite20xx
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite
Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

聊聊Go语言的全局变量

三月 22, 2023
0 条评论

本文永久链接 – https://tonybai.com/2023/03/22/global-variable-in-go

注：上面篇首配图的底图由百度文心一格生成。

C语言是Go语言的先祖之一，Go继承了很多C语言的语法与表达方式，这其中就包含了全局变量，虽然Go在其语法规范中并没有直接给出全局变量的定义。但是已经入门Go的童鞋都知道，在Go中包的导出变量(exported variable)起到的就是全局变量的作用。Go包导出变量与C的全局变量在优缺点与使用方式也有相似之处。

我是C程序员出身，对全局变量并不陌生，因此学习Go语言全局变量时，也没有太多Gap。不过来自其他语言(比如Java)的童鞋在学习Go全局变量时可能会觉得别扭，在全局变量的使用方式的理解方面也久久不能到位。

在这一篇中，我们就来聊聊Go语言的全局变量，和大家一起系统地理解一下。

一. Go中的全局变量

全局变量是一个可以在整个程序中被访问和修改的变量，不管它在哪里被定义。不同的编程语言有着不同的声明和使用全局变量的方式。

在Python中，你可以在module的任何地方声明一个全局变量。就像下面示例中的globvar。但是如果你想给它重新赋值，则需要在函数中使用global关键字。

globvar = 0

def set_globvar_to_one():
  global globvar # 要给全局变量globvar赋值
  globvar = 1

def print_globvar():
  print(globvar) # 读取全局变量globvar时无需global关键字

set_globvar_to_one()
print_globvar() # 打印1

Java中没有全局变量的概念，但你却可以使用一个类的public静态变量来模拟全局变量的作用，因为这样的public类静态变量可以被任何其他类在任何地方访问到。比如下面Java代码中globalVar：

public class GlobalExample {

  // 全局变量
  public static int globalVar = 10;

  // 全局常量
  public static final String GLOBAL_CONST = "Hello";

}

在Go中，全局变量指的是在包的最顶层声明的头母大写的导出变量，这样这个变量在整个Go程序的任何角落都可以被访问和修改，比如下面示例代码中foo包的变量Global：

package foo

var Global = "myvalue" // Go全局变量

package bar

import "foo"

func F1() {
    println(foo.Global)
    foo.Global = "another value"
}

foo.Global可以被任何导入foo包的其他包所读取和修改，就像上面代码F1中对它的那些操作。

即便是全局变量，按Go语法规范，上述Global变量的作用域也是package block的，而非universe block的，关于Go标识符的作用域，Go语言第一课专栏第11讲有系统详细地说明。

Go导出变量在Go中既然充当着全局变量的角色，它也就有了和其他语言全局变量一样的优劣势。接下来我们就来看看全局变量的优点与不足。

二. 全局变量的优缺点

俗话说：既然存在就有存在的“道理”！我们不去探讨“存在即合理”在哲学层面是否正确，我们先来看看全局变量的存在究竟能带来哪些好处。

1. 全局变量的优点

首先，全局变量易于访问。

全局变量的定义决定了它可以在程序的任何地方被访问。无论是在函数、方法、循环体内、深度缩进的条件语句块内部，全局变量都可以被直接访问到。这为减少函数参数个数带来一定“便利”，同时也省去了确定参数类型、实施参数传递的“烦恼”。

破壁人：全局变量容易被意外修改或被局部变量遮蔽，从而导致意想不到的问题。

其次，全局变量易于共享数据。

由于易于访问的特性，全局变量常用于在程序的不同部分之间共享数据，比如配置项数据、命令行标志(cmd flag)等。又由于全局变量的生命周期与程序的整个生命周期等同，不会因为函数调用结束而销毁，也不会被GC掉，可以始终存在并保持其值。因此全局变量被用作共享数据时，开发人员也不会有担心全局变量所在内存“已被回收”的心智负担。

破壁人: 并发的多线程或多协程(包括goroutine)访问同一个全局变量时需要考虑“数据竞争”问题。

最后，全局变量让代码显得更为简洁。

Go全局变量只需要在包的顶层声明一次即可，之后便可以在程序的任何地方对其进行访问和修改。对于声明全局变量的包的维护者而言，这样的代码再简洁不过了！

破壁人: 多处访问和修改全局变量的代码都与全局变量产生了直接的数据耦合，降低了可维护性和扩展性。

在上面的说明中，我针对全局变量的每条优点都写了一条“破壁人”观点，把这些破壁观点聚拢起来，就构成了全局变量的缺点集合，我们继续来看一下。

2. 全局变量的缺点

首先，全局变量容易被意外修改或被局部变量遮蔽。

前面提到，全局变量易于访问，这意味着所有地方都可能会直接访问或修改全局变量。任何一个位置改变了全局变量，都可能会以意想不到的方式影响着另外一个使用它的函数。这将导致针对这些函数的测试更为困难，全局变量的存在让各个测试之间隔离性不好，测试用例执行过程中如果修改了全局变量，测试执行结束前可能都需要将全局变量恢复到之前的状态，以尽可能保证对其他测试用例的干扰最小，下面是一个示例：

var globalVar int

func F1() {
    globalVar = 5
}

func F2() {
    globalVar = 6
}

func TestF1(t *testing) {
    old := globalVar
    F1()
    // assert the result
    ... ...
    globalVar = old // 恢复globalVar
}

func TestF2(t *testing) {
    old := globalVar
    F2()
    // assert the result
    ... ...
    globalVar = old // 恢复globalVar
}

此外，全局变量十分容易被函数、方法、循环体的同名局部变量所遮蔽(shadow)，导致一些奇怪难debug的问题，尤其是与Go的短变量声明语法结合使用时。

go vet支持对代码的静态分析，不过变量遮蔽检查的功能需要额外安装：

$go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest
$go vet -vettool=$(which shadow)

其次，并发条件下，对全局变量的访问存在“数据竞争”问题

如果你的程序存在多个goroutine对全局变量的并发读写，那么“数据竞争”问题便不可避免。你需要使用额外的同步手段对全局变量进行保护，比如互斥锁、读写锁、原子操作等。

同理，没有同步手段保护的全局变量也限制了单元测试的并行执行能力(-paralell)。

最后，全局变量在带来代码简洁性的同时，更多带来的是对扩展和复用不利的耦合性！

全局变量让程序中所有访问和修改它的代码对其产生了数据耦合，全局变量的细微变化都将对这些代码产生影响。这样，如果要复用或扩展这些依赖全局变量的代码将变得十分困难。比如：若要对它们进行并行化执行，需要考虑其耦合的全局变量是否支持同步手段。若要复用其中的代码逻辑到其他程序中，可能还需要在新程序中创建一个新的全局变量。

我们看到，Go全局变量有优点，更有一堆不足，那么我们在实际生产编码过程中到底该如何对待全局变量呢？我们继续往下看。

三. Go全局变量的使用惯例与替代方案

到底Go语言是如何对待全局变量的？我翻了翻标准库来看看Go官方团队是如何对待全局变量的，我得到的结论是尽量少用。

Go标准库中的全局变量用了“不少”，但绝大多数都是全局的“哨兵”错误变量，比如：

// $GOROOT/src/io/io.go
var ErrShortWrite = errors.New("short write")

// ErrShortBuffer means that a read required a longer buffer than was provided.
var ErrShortBuffer = errors.New("short buffer")

// EOF is the error returned by Read when no more input is available.
// (Read must return EOF itself, not an error wrapping EOF,
// because callers will test for EOF using ==.)
// Functions should return EOF only to signal a graceful end of input.
// If the EOF occurs unexpectedly in a structured data stream,
// the appropriate error is either ErrUnexpectedEOF or some other error
// giving more detail.
var EOF = errors.New("EOF")

// ErrUnexpectedEOF means that EOF was encountered in the
// middle of reading a fixed-size block or data structure.
var ErrUnexpectedEOF = errors.New("unexpected EOF")
... ...

关于错误处理中的“哨兵”错误处理模式，可以参考我的Go语言第一课专栏。更多Go错误处理模式在专栏中有系统讲解。

这些ErrXXX全局变量虽说是被定义为了“变量(Var)”，但Go开源许久以来，大家已经达成默契：这些ErrXXX变量仅是“只读”的，没人会对其进行任何修改操作。到这里有初学者可能会问：那为什么不将它们定义为常量呢？那是因为Go语言对常量的类型是有要求的：

Go常量有布尔常量、rune常量、整数常量、浮点常量、复数常量和字符串常量。

其他类型均不能被定义为常量。而errors.New返回的动态类型为errors.errorString结构体类型的指针，显然也不在常量类型范围之内。

除了ErrXXX这类全局变量外，Go标准库中其他全局变量就很少了。一个典型的全局变量是http.DefaultServeMux：

// $GOROOT/src/net/http/server.go

// DefaultServeMux is the default ServeMux used by Serve.
var DefaultServeMux = &defaultServeMux

var defaultServeMux ServeMux

// NewServeMux allocates and returns a new ServeMux.
func NewServeMux() *ServeMux { return new(ServeMux) }

http包是Go早期就携带的高频使用的包，我猜早期实现时出于某种原因定义了全局变量DefaultServeMux，后期可能由于兼容性原因保留了该全局变量，但从代码逻辑来看，去掉也不会有任何影响。

通过http包的DefaultServeMux、defaultServeMux和NewServeMux等逻辑，我们也可以看出Go语言采用的替代全局变量的方案，那就是“封装”。以http.ServeMux为例(我们假设删除掉DefaultServeMux这个全局变量，用包级非导出变量defaultServeMux替代它)。

http包定义了ServeMux类型以及相应方法用于处理HTTP请求的多路复用，但http包并未直接定义一个ServerMux的全局变量(我们假设删除了DefaultServeMux变量)，而是定义了一个包级非导出变量defaultServeMux作为默认的Mux。

http包仅导出两个函数Handle和HandleFunc供调用者注册http请求路径与对应的handler(下面代码中的DefaultServeMux可换成defaultServeMux)：

// $GOROOT/src/net/http/server.go

// Handle registers the handler for the given pattern
// in the DefaultServeMux.
// The documentation for ServeMux explains how patterns are matched.
func Handle(pattern string, handler Handler) { DefaultServeMux.Handle(pattern, handler) }

// HandleFunc registers the handler function for the given pattern
// in the DefaultServeMux.
// The documentation for ServeMux explains how patterns are matched.
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
    DefaultServeMux.HandleFunc(pattern, handler)
}

这样http完全不需要暴露Mux实现的细节，调用者也无需依赖一个全局变量，这个方案将原先的对全局变量的数据耦合转换为对http包的行为耦合。

类似的作法我们在标准库log包中也能看到，log包定义了包级变量std用作默认的Logger，但对外仅暴露Printf等系列打印函数，这些函数的实现会使用包级变量std的相应方法：

// $GOROOT/src/log/log.go

// Print calls Output to print to the standard logger.
// Arguments are handled in the manner of fmt.Print.
func Print(v ...any) {
    if std.isDiscard.Load() {
        return
    }
    std.Output(2, fmt.Sprint(v...))
}

// Printf calls Output to print to the standard logger.
// Arguments are handled in the manner of fmt.Printf.
func Printf(format string, v ...any) {
    if std.isDiscard.Load() {
        return
    }
    std.Output(2, fmt.Sprintf(format, v...))
}

// Println calls Output to print to the standard logger.
// Arguments are handled in the manner of fmt.Println.
func Println(v ...any) {
    if std.isDiscard.Load() {
        return
    }
    std.Output(2, fmt.Sprintln(v...))
}
... ...

注：其他语言可能有一些其他的替代全局变量的方案，比如Java的依赖注入。

四. 小结

综上，全局变量虽然有易于访问、易于共享、代码简洁等优点，但相较于其带来的意外修改、并发数据竞争、更高的耦合性等弊端而言，Go开发者选择了“尽量少用全局变量”的最佳实践。

此外，在Go中最常见的替代全局变量的方案就是封装，这个大家可以通过阅读标准库的典型源码慢慢体会。

注：本文部分内容来自于New Bing的Chat功能(据说是基于GPT-4大语言模型)生成的答案。