Go语言map类型变量背后的那些事儿

本文永久链接 – https://tonybai.com/2022/03/15/the-underlying-of-a-map-type-variable

切片(slice)和map是Go语言中最常用的两种原生复合数据类型,同时也是最容易使初学者感觉迷惑和“掉坑”的两个类型,这很大程度是因为Go runtime层的存在。什么是Go runtime层?可以参考我在《Go语言第一课FAQ》中的解释。

我们在Go用户源码层看到的切片与map是这样的:

var sl = make([]int, 3)
var m = make(map[string]int)

但在runtime层,它们又是另一幅“样子”。Go用户源码层的切片和map类型的变量,我常将它们称为“描述符”,因为它们和linux平台上通过open系统调用打开的文件描述符的功用十分类似,都是某个大块头儿数据(比如:一个500M的文本数据)的“代言人”,避免了和外界交互时对底层数据的搬动与拷贝。

很多人知道,在runtime层,切片是一个三元组结构(在我的“Go语言第一课”专栏中有单独一讲详细讲解),这里假定这个三元组结构为T,那么上面例子中通过make创建的切片m是类型T的实例还是*T的实例呢?很多人都知道答案:类型T的实例

同样看过我的专栏《Go语言精进之路》一书的读者也都知道:map类型在runtime层的表示为runtime.hmap,那么,上面通过make创建的map[string]int类型变量m究竟就是hmap类型实例还是*hmap类型实例呢?可能有些朋友还不明确,这里我们就来简单探究一下。

注:探究方法同样适用于切片类型。

m是hmap类型实例还是*hmap类型实例呢?最直接的方法是看runtime包的源码。在runtime/map.go中,我们找到了对应make(map[string]int)的源码makemap(或makemap_small):

func makemap(t *maptype, hint int, h *hmap) *hmap
func makemap_small() *hmap

我们看到:无论哪个函数返回的都是*hmap类型。到这里你的心里似乎有点倾向了,应该是*hmap。但还不那么确认。

我们假设m是*hmap,那么根据Go指针类型的定义(关于Go指针,我在专栏《聊聊Go语言中的指针》一讲中有较为全面讲解),Go为变量m分配的内存块中存储的值就应该是一个hmap实例的地址:

也就是说给m分配一块可以存储指针值的内存块儿即可。这样我们就可以通过相邻变量间的地址间隔来判定m是否仅仅是一个指针大小的内存块了。我们看下面例子:

package main

func main() {
    var a int = 5
    println("&a=", &a)
    var m1 = make(map[string]int)
    println("&m1=", &m1)
    var m2 = make(map[string]int)
    println("&m2=", &m2)
}

运行这个程序,输出结果如下:

&a=  0xc000046558
&m1= 0xc000046568
&m2= 0xc000046560

由于这些变量都分配在栈上(通过go build -gcflags ‘-m’可判断是否逃逸),我们用一幅图来展示一下上面示例中各个变量的内存块排列情况:

从m1与m2两个map类型变量的地址间隔情况来看,间隔8个字节,也就是一个指针大小,基本可以断定m2是指针类型实例了。

那么m是否是*hmap类型实例呢?如果是,我们是否可以通过对m的“解引用”得到该实例的值呢?我们下面试一下。

由于hmap是runtime包的非导出类型,所以我们无法在用户层直接使用,考虑到hmap都是由一些基本类型字段组成并且与runtime包的其他类型关联不多,我这里直接将其相关源码copy到示例源码中备用了。

package main

import (
    "fmt"
    "runtime"
    "unsafe"
)

type hmap struct {
    count     int // # live cells == size of map.  Must be first (used by len() builtin)
    flags     uint8
    B         uint8  // log_2 of # of buckets (can hold up to loadFactor * 2^B items)
    noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details
    hash0     uint32 // hash seed

    buckets    unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.
    oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing
    nevacuate  uintptr        // progress counter for evacuation (buckets less than this have been evacuated)

    extra *mapextra // optional fields
}

// mapextra holds fields that are not present on all maps.
type mapextra struct {
    overflow    *[]*bmap
    oldoverflow *[]*bmap

    nextOverflow *bmap
}

// A bucket for a Go map.
type bmap struct {
    tophash [bucketCnt]uint8
}

const (
    // Maximum number of key/elem pairs a bucket can hold.
    bucketCntBits = 3
    bucketCnt     = 1 << bucketCntBits
)

func main() {
    m := make(map[string]int)
    m["tony"] = 11
    m["bai"] = 12
    p := (*hmap)(unsafe.Pointer(*(*uintptr)((unsafe.Pointer)(&m))))
    fmt.Printf("%#v\n", *p)
}

这个例子中最难理解的就是变量p的声明与赋初值那一行,对于这一行我们分解来讲一下。

首先,前面我们说过:map类型变量m是指针,其存储的是一个hmap类型实例的地址。通过

*(*uintptr)((unsafe.Pointer)(&m))

我们得到的是m指向的那个hmap类型实例的地址。

然后通过将其转换为*hmap类型,我们就相当于直接得到了一个指向hmap类型实例地址的*hmap类型变量p。通过对p进行解引用,我们就能看到hmap结构体的内容了。运行上面代码我们得到下面输出结果:

main.hmap{count:2, flags:0x0, B:0x0, noverflow:0x0, hash0:0x42833520, buckets:(unsafe.Pointer)(0xc000072ea0), oldbuckets:(unsafe.Pointer)(nil), nevacuate:0x0, extra:(*main.mapextra)(nil)}

当我们看到输出结果中hmap.count这个字段(表示当前map中存储的键值对的个数)的值为2,我们就可以确定:m就是一个执行hmap结构体实例的指针这一结论是正确的。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商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
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

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

聊聊Go语言的软件供应链安全

本文永久链接 – https://tonybai.com/2022/03/14/software-supply-chain-security-in-go

Go 12岁生日以及Go 1.18 beta1发布的博文中,Go核心团队技术负责人Russ Cox都提到了2022年Go团队将关注Go软件供应链安全,并在Go中为软件供应链提供相关工具。

提到供应链,我们立马想到的它是制造业的存在,在软件开发领域中很少提及。但是近几年,软件领域安全问题频发,使得“供应链”一词在软件开发领域浮出水面,逐渐成为热词。那么,到底啥是软件供应链呢?Go对软件供应链安全的支持现状又是怎样的呢?本文我就来简单梳理一下。

1. 什么是软件供应链?

怎么理解软件供应链呢?

传统供应链的概念可以理解为一个由各种组织、人员、技术、活动、信息和资源组成的将商品或服务从供应商转移到消费者手中的过程,这一过程从原材料开始,将其加工成中间组件乃至最终转移到消费者手中的最终产品。参考这一概念,软件供应链可以理解为软件和系统的从生产到交付全过程,是一套自动化、标准化及规模化的持续交付的流水线。通过设计和开发阶段,将生产完成的软件产品通过软件交付渠道从软件供应链运输给最终用户。

如今,人们最关心的就是软件供应链的安全问题。根据软件供应链的定义,软件供应链安全可以被理解为软件生产的整个过程中软件设计与开发的各个阶段来自编码过程、工具、设备、供应商以及最终交付渠道所共同面临的安全问题。

那究竟有哪些安全问题呢?作为专注于设计与实现的开发人员,我们更加专注于编码构建这一环节。在确定安全问题之前,我们先将前面的软件供应链的广义理解抛开,建立一个更为狭义的理解,即将软件供应链单纯视为以商业组件与开源组件等第三方组件的供应链条。在这一狭义的理解下,我们再来探讨安全问题的来由。

在开源软件兴起之前,一个公司开发出的软件大多数都是经由公司招募的专职开发者一行一行码出来的,语言标准库、C运行时库、系统原生库等集成在编程语言工具和OS层面的组件除外。

开源软件兴起后,无论是大厂巨头,还是小厂初创,都会基于大量的开源软件包来构建自己的产品。这些开源软件包呈现出多样化、复杂化的趋势。并且涉及的领域也十分广泛:从应用级库/包、开发工具、到中间件、到数据库、甚至操作系统以及设备固件。据Forrester 2021年发布的报告数据显示,开源代码占软件代码的比例从2015年到2019年的五年时间内几乎翻了一倍,如下图。

2020年,这一比例更是上升到75%

开源软件包、组件与工具的广泛采用让企业的开发效率大幅提升的同时,也让软件供应链的风险不断增加。风险主要体现在下面几个方面:

  • 安全风险

开源软件正在呈现指数级增长。根据美国国家计算机安全中心(NCSC)公开的数据显示由世界最大的源代码管理平台GitHub托管的公共存储库数量从2009年2月的46000个激增到2020年1月的2800万个。由于开源软件之间的关联依赖关系变得日益复杂,开发人员很难对其依赖的开源包/组件的所有依赖链上的包/组件做出安全评估,这样一旦依赖链上的某一开源包/组件出现未知的安全漏洞,将会导致所有与之存在依赖关系的其他软件系统出现同样的漏洞,漏洞的攻击面将会由点及面呈现出爆炸式的放大效果。并且,即便很快发现安全漏洞,开源软件包的问题修复时间也较长,一般多在1天到一周甚至更多。甚至存在具有非法目的开发者故意预留后门的安全缺陷,攻击者通过将恶意代码注入为全球软件供应链提供组件的开源项目中,借助开源软件的“高信任度”和影响力,通过感染软件供应链的“上游”组件加速向“下游”扩散,从而产生更大的破坏性。

  • 知识产权风险

主要体现在对开源许可证的理解与是否在许可证的要求下使用开源软件包/组件。一旦误用,便会给企业带来知识产权上的风险,甚至风险发生,导致企业的真实损失。

  • 断供风险

由于国际政治原因以及大国博弈,一些大国通过实行严密的技术封锁,建立完善的出口管制法律制度体系,将本国的软件、硬件和技术列入出口管制清单,这回直接导致软件供应链的完整性遭遇严重的挑战。目前在我国,这已经是发生过的事实了。

对于聚焦系统实现环节的开发者而言,安全风险始终是主要考虑的供应链风险。那么,通过哪些手段可以降低软件供应链的安全风险呢?我们继续向下看。

2. 软件供应链的安全风险控制

在软件供应链风险控制这方面,不得不说,软件强国美国走在了世界的前面:

  • 美国政府在2008年颁布《国家网络安全综合倡议》(CNCI),要求在产品、系统和服务的整个生命周期内综合应对国内和全球供应链风险。
  • 2009年奥巴马政府发布的《美国网络空间安全政策评估报告》将ICT供应链安全纳入国家安全范畴。
  • 2012年,美国国土安全部发布首个国家层级的战略报告《全球供应链安全国家战略》,提出安全和高效两大目标。
  • 2013年,美国国家标准和技术研究院(NIST)发布《联邦信息系统与机构供应链风险管理实践》。
  • 2016年,国家网络安全促进委员会发布《加强国家网络安全—促进数字经济的安全与发展》。
  • 2017年,美国国土安全部发布《供应链风险管理计划》
  • 2018年,美国白宫发布《联邦信息技术供应链风险管理改进法案》。
  • 2019年,特朗普签署《确保信息通信技术与服务供应链安全》行政令,禁止交易、使用可能对美国的国家安全、外交政策和经济构成特殊威胁的外国信息技术和服务。
  • 2021年,美国商务部发布《确保信息和通信技术及服务供应链安全》的最新规则生效,对美国国家或公民构成不可接受之风险的外国对手的信息通信技术和服务(ICTS)交易所进行识别、评估和风险消除程序,从而决定是否禁止交易。
  • 2021年5月12日,美国总统拜登发布《关于改善国家网络安全的行政命令》的14028号政令,明确要求联邦政府采取行动,迅速提高软件供应链的安全性和完整性。

我们重点关注一下2021年拜登的《关于改善国家网络安全的行政命令》行政令,该行政令的大多内容都致力于提高软件供应链的安全性,并特别要求政府软件应包含机器可读的软件物料清单(Software Bill Of Materials, SBOM)

什么是SBOM?它被定义为“包含构建软件使用的各种组件的详细信息和供应链关系的正式记录”。它不仅应该详细说明交付的组件,还应该详细说明用于交付软件的工具和框架。SBOM是开启软件开发透明和开放时代的基础。通过机器可读的SBOM,软件的消费者可以得知哪个版本的软件包可能会影响其产品的安全性,而无需依赖软件供应商的安全警报与补丁,并且基于SBOM,消费者能够实施自己的安全控制方案,这些控制方案还可以自动化执行。SBOM使得整个行业在享受开源带来的便利和效率的同时,还可以对安全风险进行更为有效的控制与治理。

美国国家电信和信息管理局(NITA)在14028号政令的要求下,在2021年7月12日发布了《SBOM的最低要素》,该文档为各开发工具的组织和厂商提供了SBOM数据格式的参考。

软件供应链安全的上下文的铺垫有些长!下面我们来聚焦一下Go,看看Go语言在降低软件供应链安全风险方面都提供了哪些支持。

3. Go对软件供应链安全的支持情况

在GOPATH时代,Go即便想在降低软件供应链安全方面为开发者提供一些帮助可能也做不好,甚至是做不到。但Go module的引入扭转了这个局面。

1.13版本开始,Go命令在构建Go应用时会将其依赖的module版本信息嵌入到可执行程序中,同时从1.13版本开始,我们可以通过go version -m命令读取这些嵌入在可执行文件中的应用的module依赖信息。下面是一个例子:

// sbom1.go

package main

import (
    "time"

    "go.uber.org/zap"
)

func main() {
    logger, _ := zap.NewProduction()
    defer logger.Sync()
    url := "http://tonybai.com"
    logger.Info("failed to fetch URL",
        // Structured context as strongly typed Field values.
        zap.String("url", url),
        zap.Int("attempt", 3),
        zap.Duration("backoff", time.Second),
    )
}

使用[Go 1.13, Go 1.17]集合中的Go版本编译上述例子后,可以通过go version -m读取依赖module列表信息:

// 基于go 1.13.6编译sbom1.go
$go build sbom1.go

// 读取依赖module列表信息
$go version -m sbom1
sbom1: go1.13.6
    path    command-line-arguments
    mod demo1   (devel)
    dep go.uber.org/atomic  v1.7.0  h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=
    dep go.uber.org/multierr    v1.6.0  h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=
    dep go.uber.org/zap v1.21.0 h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=

我们看到:读取的列表信息中不仅包含了sbom1.go的直接依赖module的版本信息,还包括了zap包的传递依赖的module的版本信息,也就是说通过这份信息,我们可以看到sbom1的所有第三方依赖的版本,换句话说对于sbom1的使用者而言,sbom1的构成信息是公开透明的。

如果使用[go 1.11, go 1.12]集合中的Go版本编译上述例子,使用go 1.13及以上版本的go version -m查看可执行文件的依赖module信息是不会成功的:

$go version -m sbom1
sbom1: could not read Go build info from sbom1: not a Go executable

上述嵌入到可执行文件中的依赖module列表信息,就是SBOM的一部分。当然按照上面提到的美国行政令对SBOM的要求:不仅应该详细说明交付的组件,还应该详细说明用于交付软件的工具和框架,仅嵌入这些信息还不够。

于是Go 1.18版本又扩展了嵌入以及可被go version -m读取的信息范围,我们使用go 1.18rc1版本编译上面的sbom1.go并用go version -m读取得到的结果如下:

// go 1.18rc1
$go build sbom1.go
$go version -m sbom1
sbom1: go1.18rc1
    path    command-line-arguments
    dep go.uber.org/atomic  v1.7.0  h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=
    dep go.uber.org/multierr    v1.6.0  h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=
    dep go.uber.org/zap v1.21.0 h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=
    build   -compiler=gc
    build   CGO_ENABLED=1
    build   CGO_CFLAGS=
    build   CGO_CPPFLAGS=
    build   CGO_CXXFLAGS=
    build   CGO_LDFLAGS=
    build   GOARCH=amd64
    build   GOOS=darwin
    build   GOAMD64=v1

我们看到应用程序的构建信息也被嵌入到最终的可执行文件中了。

当然,除了通过go version命令可以读取Go应用的SBOM信息外,Go还在标准库中提供了API用于读取Go应用可执行文件中嵌入的SBOM信息,看下面例子:

// readsbom.go
package main

import (
    "debug/buildinfo"
    "fmt"
)

func main() {
    info, err := buildinfo.ReadFile("./sbom1")
    if err != nil {
        fmt.Println("read buildinfo error:", err)
        return
    }

    fmt.Printf("%#v\n\n", info)
    for _, d := range info.Deps {
        fmt.Printf("%#v\n", *d)
    }
}

运行这段例子:

$go run readsbom.go
&debug.BuildInfo{GoVersion:"go1.18rc1", Path:"command-line-arguments", Main:debug.Module{Path:"", Version:"", Sum:"", Replace:(*debug.Module)(nil)}, Deps:[]*debug.Module{(*debug.Module)(0xc000026180), (*debug.Module)(0xc0000261c0), (*debug.Module)(0xc000026200)}, Settings:[]debug.BuildSetting{debug.BuildSetting{Key:"-compiler", Value:"gc"}, debug.BuildSetting{Key:"CGO_ENABLED", Value:"1"}, debug.BuildSetting{Key:"CGO_CFLAGS", Value:""}, debug.BuildSetting{Key:"CGO_CPPFLAGS", Value:""}, debug.BuildSetting{Key:"CGO_CXXFLAGS", Value:""}, debug.BuildSetting{Key:"CGO_LDFLAGS", Value:""}, debug.BuildSetting{Key:"GOARCH", Value:"amd64"}, debug.BuildSetting{Key:"GOOS", Value:"darwin"}, debug.BuildSetting{Key:"GOAMD64", Value:"v1"}}}

debug.Module{Path:"go.uber.org/atomic", Version:"v1.7.0", Sum:"h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=", Replace:(*debug.Module)(nil)}
debug.Module{Path:"go.uber.org/multierr", Version:"v1.6.0", Sum:"h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=", Replace:(*debug.Module)(nil)}
debug.Module{Path:"go.uber.org/zap", Version:"v1.21.0", Sum:"h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=", Replace:(*debug.Module)(nil)}

我们看到,通过debug/buildinfo包查看到的Go应用的SBOM信息与使用go version -m查到的信息是完全一致的。

当然Go对软件供应链安全的支持措施还不仅这些,有了依赖module列表以及构建信息后,开发者还需要检测工具来检查这些“供应链上的组件”是否有安全风险。Go核心团队已经建立了Go vulnerability(漏洞) database,作为后续检测工具的漏洞数据库源。总体来说,Go核心团队对软件供应链安全提供的支持措施还在进行中(WIP),以后甚至会在go命令中提供单独的子命令来对供应链上的组件实施检测。

业界也有一些第三方的供应链安全检测工具,比如国内的“悬镜安全”就开源了一款用Go实现的软件组成分析工具OpenSCA-cli,它可基于漏洞数据库对各种语言实现的软件的供应链上的组件进行安全检测。

4. 小结

现在看来,Go之所以积极推动SBOM的落地是因为美国法律的要求。

针对美第14028号行政命令,美国的NIST发布了《开发者验证软件的最低标准指南(Guidelines on Minimum Standards for Developer Verification of Software)》。这份指南建议采取以下措施对软件进行安全验证:
- 威胁建模以寻找设计层面的安全问题
- 自动测试以保证一致性,并最大限度地减少人力投入
- 静态代码扫描,寻找最重要的漏洞
- 启发式工具来寻找可能存在的硬编码密钥
- 使用内置的检查和保护措施
- 使用”黑盒”测试用例
- 基于代码的结构测试用例
- 历史测试用例
- 模糊测试(Fuzzing)
- 网络应用程序扫描器,如果适用的话
- 解决包含的代码(库、包、服务)。

从这里也可以看到Go 1.18加入对Fuzzing的原生支持,看来很大可能也是为了响应这一指南。

5. 参考资料

  • 软件供应链安全现状与发展对策 – https://zhuanlan.zhihu.com/p/442772376
  • 悬镜安全发布的《2021软件供应链安全白皮书》,关注公众号iamtonybai,发送关键字“2021软件供应链”即可获得该白皮书。
  • Thoughtworks雷达25期 – https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2021/10/tr_technology_radar_vol_25_cn.pdf

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}

img{512x368}
img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商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
  • 微信公众号:iamtonybai
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系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