标签 Gopher 下的文章

聊聊Go语言的全局变量

本文永久链接 – 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核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商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

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

一文搞懂Go subtest

注:本篇首图片基于lexica AI生成的图片二次加工而成。

本文永久链接 – https://tonybai.com/2023/03/15/an-intro-of-go-subtest

单元测试(unit testing)是软件开发中至关重要的一环,它存在的意义包括但不限于如下几个方面:

  • 提高代码质量:单元测试可以确保代码的正确性、可靠性和稳定性,从而减少代码缺陷和bug。
  • 减少回归测试成本:在修改代码时,单元测试可以快速检查是否影响了其他模块的功能,避免了整个系统的回归测试成本。
  • 促进团队合作:单元测试可以帮助团队成员更好地理解和使用彼此编写的代码,提高代码的可读性和可维护性。
  • 提高开发效率:单元测试可以自动化执行测试,减少手动测试的时间和工作量,从而提高开发效率。

Go语言设计者在Go设计伊始就决定语言特性与环境特性“两手都要抓,两手都要硬”,事实证明:Go的成功正是因为其对工程软件项目整体环境的专注。而Go内置轻量级测试框架这一点也正是Go重视环境特性的体现。并且,Go团队对这一内置测试框架的投入是持续的,不断有更便捷的、更灵活的新特性加入Go测试框架中,可以帮助Gopher更好地组织测试代码,更高效地执行测试等。

Go在Go 1.7版本引入的subtest就是一个典型的代表,subtest的加入使得Gopher可以更灵活地应用内置go test框架。

在本文中,我将结合日常开发中了解到的关于subtest的认知、理解和使用的问题,和大家一起聊聊subtest。

一. Go单元测试回顾

在Go语言中,单元测试被视为一等公民,结合Go内置的轻量级测试框架,Go开发者可以很方便的编写单元测试用例。

Go的单元测试通常放在与被测试代码相同的包中,单元测试所在源文件以_test.go结尾,这个Go测试框架要求的。测试函数以Test为前缀,接受一个*testing.T类型的参数,并使用t.Error、t.Fail以及t.Fatal等方法来报告测试失败。使用go test命令即可运行所有的测试代码。如果测试通过,则输出一条消息表示测试成功;否则输出错误信息,指出哪些测试失败了。

注:Go还支持基准测试、example测试、模糊测试等,以便进行性能测试和文档生成,但这些不是这篇文章所要关注的内容。
注:t.Error <=> t.Log+t.Fail

通常编写Go测试代码时,我们首先会考虑top-level test。

二. Go top-level test

上面提到的与被测源码在相同目录下的*_test.go中的以Test开头的函数就是Go top-level test。在*_test.go可以定义一个或多个以Test开头的函数用于测试被测源码中函数或方法。例如:

// https://github.com/bigwhite/experiments/blob/master/subtest/add_test.go

// 被测代码,仅是demo
func Add(a, b int) int {
    return a + b
}

// 测试代码
func TestAdd(t *testing.T) {
    got := Add(2, 3)
    if got != 5 {
        t.Errorf("Add(2, 3) got %d, want 5", got)
    }
}

func TestAddZero(t *testing.T) {
    got := Add(2, 0)
    if got != 2 {
        t.Errorf("Add(2, 0) got %d, want 2", got)
    }
}

func TestAddOppositeNum(t *testing.T) {
    got := Add(2, -2)
    if got != 0 {
        t.Errorf("Add(2, -2) got %d, want 0", got)
    }
}

注:“got-want”是Go test中在Errorf中常用的命名惯例

top-level test的执行有如下特点:

  • go test会将每个TestXxx放在单独的goroutine中执行,保持相互的隔离
  • 某个TestXxx用例未过,通过Errorf,甚至是Fatalf输出错误结果,都不会影响到其他TestXxx的执行;
  • 某个TestXxx用例中的某个结果判断未过,如果通过Errorf输出错误结果,则该TestXxx会继续执行;
  • 不过,如果TestXxx使用的是Fatal/Fatalf,这会导致该TestXxx的执行在调用Fatal/Fatalf的位置立即结束,TestXxx函数体内的后续测试代码将不会得到执行;
  • 默认各个TestXxx按声明顺序逐一执行,即便它们是在各自的goroutine中执行的;
  • 通过go test -shuffle=on可以让各个TestXxx按随机次序执行,这样可以检测出各个TestXxx之间是否存在执行顺序的依赖,我们要避免在测试代码中出现这种依赖;
  • 通过“go test -run=正则式”的方式,可以选择执行某些TestXxx。
  • 各个TestXxx函数可以调用t.Parallel方法(即testing.T.Parallel方法)来将TestXxx加入到可并行执行的用例集合中,注意:加入到并行执行集合后,这些TestXxx的执行顺序就不确定了。

结合属于Go最佳实践的表驱动(table-driven)测试(如下面代码TestAddWithTable所示),我们可以无需写很多TestXxx,用下面的TestAddWithTable即可实现上面三个TestXxx的等价测试:

func TestAddWithTable(t *testing.T) {
    cases := []struct {
        name string
        a    int
        b    int
        r    int
    }{
        {"2+3", 2, 3, 5},
        {"2+0", 2, 0, 2},
        {"2+(-2)", 2, -2, 0},
        //... ...
    }

    for _, caze := range cases {
        got := Add(caze.a, caze.b)
        if got != caze.r {
            t.Errorf("%s got %d, want %d", caze.name, got, caze.r)
        }
    }
}

Go top-level test可以满足大多数Gopher的常规单测需求,表驱动的惯例理解起来也十分容易。

但基于top-level test+表驱动的测试在简化测试代码编写的同时,也会带来一些不足:

  • 表内的cases顺序执行,无法shuffle;
  • 表内所有cases在同一个goroutine中执行,隔离性差;
  • 如果使用fatal/fatalf,那么一旦某个case失败,后面的测试表项(cases)将不能得到执行;
  • 表内test case无法并行(parallel)执行;
  • 测试用例的组织只能平铺,不够灵活,无法建立起层次。

为此Go 1.7版本引入了subtest!

三. Subtest

Go语言的subtest是指将一个测试函数(TestXxx)分成多个小测试函数,每个小测试函数可以独立运行并报告测试结果的功能。这种测试方式可以更细粒度地控制测试用例,方便定位问题和调试。

下面是一个使用subtest改造TestAddWithTable的示例代码,展示如何使用Go语言编写subtest:

// https://github.com/bigwhite/experiments/blob/master/subtest/add_sub_test.go

func TestAddWithSubtest(t *testing.T) {
    cases := []struct {
        name string
        a    int
        b    int
        r    int
    }{
        {"2+3", 2, 3, 5},
        {"2+0", 2, 0, 2},
        {"2+(-2)", 2, -2, 0},
        //... ...
    }

    for _, caze := range cases {
        t.Run(caze.name, func(t *testing.T) {
            t.Log("g:", curGoroutineID())
            got := Add(caze.a, caze.b)
            if got != caze.r {
                t.Errorf("got %d, want %d", got, caze.r)
            }
        })
    }
}

在上面的代码中,我们定义了一个名为TestAddWithSubtest的测试函数,并在其中使用t.Run()方法结合表测试方式来创建三个subtest,这样每个subtest都可以复用相同的错误处理逻辑,但通过测试用例参数的不同来体现差异。当然你若不使用表驱动测试,那么每个subtest也都可以有自己独立的错误处理逻辑!

执行上面TestAddWithSubtest这个测试用例(我们故意将Add函数的实现改成错误的),我们将看到下面结果:

$go test  add_sub_test.go
--- FAIL: TestAddWithSubtest (0.00s)
    --- FAIL: TestAddWithSubtest/2+3 (0.00s)
        add_sub_test.go:54: got 6, want 5
    --- FAIL: TestAddWithSubtest/2+0 (0.00s)
        add_sub_test.go:54: got 3, want 2
    --- FAIL: TestAddWithSubtest/2+(-2) (0.00s)
        add_sub_test.go:54: got 1, want 0

我们看到:在错误信息输出中,每个失败case都是以“TestXxx/subtestName”标识,我们可以很容易地将其与相应的代码行对应起来。更深层的意义是subtest让整个测试组织形式有了“层次感”!通过-run标志位,我们便能够以这种“层次”选择要执行的某个top-level test的某个/某些Subtest:

$go test  -v -run TestAddWithSubtest/-2 add_sub_test.go
=== RUN   TestAddWithSubtest
=== RUN   TestAddWithSubtest/2+(-2)
    add_sub_test.go:51: g: 19
    add_sub_test.go:54: got 1, want 0
--- FAIL: TestAddWithSubtest (0.00s)
    --- FAIL: TestAddWithSubtest/2+(-2) (0.00s)
FAIL
FAIL    command-line-arguments  0.006s
FAIL

我们来看看subtest有哪些特点(可以和前面的top-level test对比着看):

  • go subtest也会放在单独的goroutine中执行,保持相互的隔离
  • 某个Subtest用例未过,通过Errorf,甚至是Fatalf输出错误结果,都不会影响到同一TestXxx下的其他Subtest的执行;
  • 某个Subtest中的某个结果判断未过,如果通过Errorf输出错误结果,则该Subtest会继续执行;
  • 不过,如果subtest使用的是Fatal/Fatalf,这会导致该subtest的执行在调用Fatal/Fatalf的位置立即结束,subtest函数体内的后续测试代码将不会得到执行;
  • 默认各个TestXxx下的subtest将按声明顺序逐一执行,即便它们是在各自的goroutine中执行的;
  • 到目前为止,subtest不支持shuffle方式的随机序执行
  • 通过“go test -run=TestXxx/正则式[/...]”的方式,我们可以选择执行TestXxx下的某个或某些subtest;
  • 各个subtest可以调用t.Parallel方法(即testing.T.Parallel方法)来将subtest加入到可并行执行的用例集合中,注意:加入到并行执行集合后,这些subTest的执行顺序就不确定了。

综上,subtest的优点可以总结为以下几点:

  • 更细粒度的测试:通过将测试用例分成多个小测试函数,可以更容易地定位问题和调试。
  • 可读性更好:subtest可以让测试代码更加清晰和易于理解。
  • 更灵活的测试:subtest可以根据需要进行组合和排列,以满足不同的测试需求。
  • 更有层次的组织测试代码:通过subtest可以设计出更有层次的测试代码组织形式,更方便地共享资源和在某一组织层次上设置setup与teardown,我的《Go语言精进之路》vol2的第41条“有层次地组织测试代码”对这方面内容有系统说明,大家可以参考。

四. Subtest vs. top-level test

top-level test自身其实也是一种subtest,只是在它的调度与执行是由Go测试框架掌控的的,对我们开发人员并不可见。

对于gopher而言:

  • 简单的包的测试在top-level test中就可以满足,直接、直观、易懂。
  • 对于稍大一些的工程中的复杂包来说,一旦涉及到测试代码组织的层次设计时,subtest的组织性、灵活性和可扩展性便可以更好地的帮助我们提高测试效率和减少测试时间。

注:本文少部分内容来自于ChatGPT生成的答案。

本文涉及的源码可以在这里下载。


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

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商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

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats