本文永久链接 – https://tonybai.com/2023/03/30/automated-testing-driven-by-go-test

一. 背景

团队的测试人员稀缺，无奈只能“自己动手，丰衣足食”，针对我们开发的系统进行自动化测试，这样既节省的人力，又提高了效率，还增强了对系统质量保证的信心。

我们的目标是让自动化测试覆盖三个环境，如下图所示：

我们看到这三个环境分别是：

• CI/CD流水线上的自动化测试
• 发版后在各个stage环境中的自动化冒烟/验收测试
• 发版后在生产环境的自动化冒烟/验收测试

我们会建立统一的用例库或针对不同环境建立不同用例库，但这些都不重要，重要的是我们用什么语言来编写这些用例、用什么工具来驱动这些用例。

下面看看方案的诞生过程。

二. 方案

最初组内童鞋使用了YAML文件来描述测试用例，并用Go编写了一个独立的工具读取这些用例并执行。这个工具运作起来也很正常。但这样的方案存在一些问题：

• 编写复杂

编写一个最简单的connect连接成功的用例，我们要配置近80行yaml。一个稍微复杂的测试场景，则要150行左右的配置。

• 难于扩展

由于最初的YAML结构设计不足，缺少了扩展性，使得扩展用例时，只能重新建立一个用例文件。

• 表达能力不足

我们的系统是消息网关，有些用例会依赖一定的时序，但基于YAML编写的用例无法清晰地表达出这种用例。

• 可维护性差

如果换一个人来编写新用例或维护用例，这个人不仅要看明白一个个百十来行的用例描述，还要翻看一下驱动执行用例的工具，看看其执行逻辑。很难快速cover这个工具。

为此我们想重新设计一个工具，测试开发人员可以利用该工具支持的外部DSL文法来编写用例，然后该工具读取这些用例并执行。

注：根据Martin Fowler的《领域特定语言》一书对DSL的分类，DSL有三种选型：通用配置文件(xml, json, yaml, toml)、自定义领域语言，这两个合起来称为外部DSL。如：正则表达式、awk, sql、xml等。利用通用编程语言片段/子集作为DSL则称为内部dsl，像ruby等。

后来基于待测试的场景数量和用例复杂度粗略评估了一下DSL文法(甚至借助ChatGPT生成过几版DSL文法)，发现这个“小语言”那也是“麻雀虽小五脏俱全”。如果用这样的DSL编写用例，和利用通用语言(比如Python)编写的用例在代码量级上估计也不相上下了。

既然如此，自己设计外部DSL意义也就不大了。还不如用Python来整。但转念一想，既然用通用语言的子集了，团队成员对Python又不甚熟悉，那为啥不回到Go呢^_^。

让我们进行一个大胆的设定：将Go testing框架作为“内部DSL”来编写用例，用go test命令作为执行这些用例的测试驱动工具。此外，有了GPT-4加持，生成TestXxx、补充用例啥的应该也不是大问题。

下面我们来看看如何组织和编写用例并使用go test驱动进行自动化测试。

三. 实现

1. 测试用例组织

我的《Go语言精进之路vol2》书中的第41条“有层次地组织测试代码”中对基于go test的测试用例组织做过系统的论述。结合Go test提供的TestMain、TestXxx与sub test，我们完全可以基于go test建立起一个层次清晰的测试用例结构。这里就以一个对开源mqtt broker的自动化测试为例来说明一下。

注：你可以在本地搭建一个单机版的开源mqtt broker服务作为被测对象，比如使用Eclipse的mosquitto。

在组织用例之前，我先问了一下ChatGPT对一个mqtt broker测试都应该包含哪些方面的用例，ChatGPT给了我一个简单的表：

如果你对MQTT协议有所了解，那么你应该觉得ChatGPT给出的答案还是很不错的。

这里我们就以connection、subscribe和publish三个场景(scenario)来组织用例：

$tree -F .
.
├── Makefile
├── go.mod
├── go.sum
├── scenarios/
│   ├── connection/              // 场景：connection
│   │   ├── connect_test.go      // test suites
│   │   └── scenario_test.go
│   ├── publish/                 // 场景：publish
│   │   ├── publish_test.go      // test suites
│   │   └── scenario_test.go
│   ├── scenarios.go             // 场景中测试所需的一些公共函数
│   └── subscribe/               // 场景：subscribe
│       ├── scenario_test.go
│       └── subscribe_test.go    // test suites
└── test_report.html             // 生成的默认测试报告

简单说明一下这个测试用例组织布局：

• 我们将测试用例分为多个场景(scenario)，这里包括connection、subscribe和publish；
• 由于是由go test驱动，所以每个存放test源文件的目录中都要遵循Go对Test的要求，比如：源文件以_test.go结尾等。
• 每个场景目录下存放着测试用例文件，一个场景可以有多个_test.go文件。这里设定_test.go文件中的每个TestXxx为一个test suite，而TestXxx中再基于subtest编写用例，这里每个subtest case为一个最小的test case；
• 每个场景目录下的scenario_test.go，都是这个目录下包的TestMain入口，主要是考虑为所有包传入统一的命令行标志与参数值，同时你也针对该场景设置在TestMain中设置setup和teardown。该文件的典型代码如下：

// github.com/bigwhite/experiments/automated-testing/scenarios/subscribe/scenario_test.go

package subscribe

import (
    "flag"
    "log"
    "os"
    "testing"

    mqtt "github.com/eclipse/paho.mqtt.golang"
)

var addr string

func init() {
    flag.StringVar(&addr, "addr", "", "the broker address(ip:port)")
}

func TestMain(m *testing.M) {
    flag.Parse()

    // setup for this scenario
    mqtt.ERROR = log.New(os.Stdout, "[ERROR] ", 0)

    // run this scenario test
    r := m.Run()

    // teardown for this scenario
    // tbd if teardown is needed

    os.Exit(r)
}

接下来我们再来看看具体测试case的实现。

2. 测试用例实现

我们以稍复杂一些的subscribe场景的测试为例，我们看一下subscribe目录下的subscribe_test.go中的测试suite和cases：

// github.com/bigwhite/experiments/automated-testing/scenarios/subscribe/subscribe_test.go

package subscribe

import (
    scenarios "bigwhite/autotester/scenarios"
    "testing"
)

func Test_Subscribe_S0001_SubscribeOK(t *testing.T) {
    t.Parallel() // indicate the case can be ran in parallel mode

    tests := []struct {
        name  string
        topic string
        qos   byte
    }{
        {
            name:  "Case_001: Subscribe with QoS 0",
            topic: "a/b/c",
            qos:   0,
        },
        {
            name:  "Case_002: Subscribe with QoS 1",
            topic: "a/b/c",
            qos:   1,
        },
        {
            name:  "Case_003: Subscribe with QoS 2",
            topic: "a/b/c",
            qos:   2,
        },
    }

    for _, tt := range tests {
        tt := tt
        t.Run(tt.name, func(t *testing.T) {
            t.Parallel() // indicate the case can be ran in parallel mode
            client, testCaseTeardown, err := scenarios.TestCaseSetup(addr, nil)
            if err != nil {
                t.Errorf("want ok, got %v", err)
                return
            }
            defer testCaseTeardown()

            token := client.Subscribe(tt.topic, tt.qos, nil)
            token.Wait()

            // Check if subscription was successful
            if token.Error() != nil {
                t.Errorf("want ok, got %v", token.Error())
            }

            token = client.Unsubscribe(tt.topic)
            token.Wait()
            if token.Error() != nil {
                t.Errorf("want ok, got %v", token.Error())
            }
        })
    }
}

func Test_Subscribe_S0002_SubscribeFail(t *testing.T) {
}

这个测试文件中的测试用例与我们日常编写单测并没有什么区别！有一些需要注意的地方是：

• Test函数命名

这里使用了Test_Subscribe_S0001_SubscribeOK、Test_Subscribe_S0002_SubscribeFail命名两个Test suite。命名格式为：

Test_场景_suite编号_测试内容缩略

之所以这么命名，一来是测试用例组织的需要，二来也是为了后续在生成的Test report中区分不同用例使用。

• testcase通过subtest呈现

每个TestXxx是一个test suite，而基于表驱动的每个sub test则对应一个test case。

• test suite和test case都可单独标识为是否可并行执行

通过testing.T的Parallel方法可以标识某个TestXxx或test case(subtest)是否是可以并行执行的。

• 针对每个test case，我们都调用setup和teardown

这样可以保证test case间都相互独立，互不影响。

3. 测试执行与报告生成

设计完布局，编写完用例后，接下来就是执行这些用例。那么怎么执行这些用例呢？

前面说过，我们的方案是基于go test驱动的，我们的执行也要使用go test。

在顶层目录automated-testing下，执行如下命令：

$go test ./... -addr localhost:30083

go test会遍历执行automated-testing下面每个包的测试，在执行每个包的测试时会将-addr这个flag传入。如果localhost:30083端口并没有mqtt broker服务监听，那么上面的命令将输出如下信息：

$go test ./... -addr localhost:30083
?       bigwhite/autotester/scenarios   [no test files]
[ERROR] [client]   dial tcp [::1]:30083: connect: connection refused
[ERROR] [client]   Failed to connect to a broker
--- FAIL: Test_Connection_S0001_ConnectOKWithoutAuth (0.00s)
    connect_test.go:20: want ok, got network Error : dial tcp [::1]:30083: connect: connection refused
FAIL
FAIL    bigwhite/autotester/scenarios/connection    0.015s
[ERROR] [client]   dial tcp [::1]:30083: connect: connection refused
[ERROR] [client]   Failed to connect to a broker
--- FAIL: Test_Publish_S0001_PublishOK (0.00s)
    publish_test.go:11: want ok, got network Error : dial tcp [::1]:30083: connect: connection refused
FAIL
FAIL    bigwhite/autotester/scenarios/publish   0.016s
[ERROR] [client]   dial tcp [::1]:30083: connect: connection refused
[ERROR] [client]   dial tcp [::1]:30083: connect: connection refused
[ERROR] [client]   Failed to connect to a broker
[ERROR] [client]   Failed to connect to a broker
[ERROR] [client]   dial tcp [::1]:30083: connect: connection refused
[ERROR] [client]   Failed to connect to a broker
--- FAIL: Test_Subscribe_S0001_SubscribeOK (0.00s)
    --- FAIL: Test_Subscribe_S0001_SubscribeOK/Case_002:_Subscribe_with_QoS_1 (0.00s)
        subscribe_test.go:39: want ok, got network Error : dial tcp [::1]:30083: connect: connection refused
    --- FAIL: Test_Subscribe_S0001_SubscribeOK/Case_003:_Subscribe_with_QoS_2 (0.00s)
        subscribe_test.go:39: want ok, got network Error : dial tcp [::1]:30083: connect: connection refused
    --- FAIL: Test_Subscribe_S0001_SubscribeOK/Case_001:_Subscribe_with_QoS_0 (0.00s)
        subscribe_test.go:39: want ok, got network Error : dial tcp [::1]:30083: connect: connection refused
FAIL
FAIL    bigwhite/autotester/scenarios/subscribe 0.016s
FAIL

这也是一种测试失败的情况。

在自动化测试时，我们一般会把错误或成功的信息保存到一个测试报告文件(多是html)中，那么我们如何基于上面的测试结果内容生成我们的测试报告文件呢？

首先go test支持将输出结果以结构化的形式展现，即传入-json这个flag。这样我们仅需基于这些json输出将各个字段读出并写入html中即可。好在有现成的开源工具可以做到这点，那就是go-test-report。下面是通过命令行管道让go test与go-test-report配合工作生成测试报告的命令行：

注：go-test-report工具的安装方法：go install github.com/vakenbolt/go-test-report@latest

$go test ./... -addr localhost:30083 -json|go-test-report
[go-test-report] finished in 1.375540542s

执行结束后，就会在当前目录下生成一个test_report.html文件，使用浏览器打开该文件就能看到测试执行结果：

通过测试报告的输出，我们可以很清楚看到哪些用例通过，哪些用例失败了。并且通过Test suite的名字或Test case的名字可以快速定位是哪个scenario下的哪个suite的哪个case报的错误！我们也可以点击某个test suite的名字，比如：Test_Connection_S0001_ConnectOKWithoutAuth，打开错误详情查看错误对应的源文件与具体的行号：

为了方便快速敲入上述命令，我们可以将其放入Makefile中方便输入执行，即在顶层目录下，执行make即可执行测试：

$make
go test ./... -addr localhost:30083 -json|go-test-report
[go-test-report] finished in 2.011443636s

如果要传入自定义的mqtt broker的服务地址，可以用：

$make broker_addr=192.168.10.10:10083

四. 小结

在这篇文章中，我们介绍了如何实现基于go test驱动的自动化测试，介绍了这样的测试的结构布局、用例编写方法、执行与报告生成等。

这个方案的不足是要求测试用例所在环境需要部署go与go-test-report。

go test支持将test编译为一个可执行文件，不过不支持将多个包的测试编译为一个可执行文件：

$go test -c ./...
cannot use -c flag with multiple packages

此外由于go test编译出的可执行文件不支持将输出内容转换为JSON格式，因此也无法对接go-test-report将测试结果保存在文件中供后续查看。

本文涉及的源码可以在这里下载 – https://github.com/bigwhite/experiments/tree/master/automated-testing

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

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

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

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

本文永久链接 – 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大语言模型)生成的答案。

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

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

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite

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