Etcd | Tony Bai

标签 etcd 下的文章

2021年Go语言盘点：厉兵秣马强技能，蓄势待发新征程

一月 16, 2022
2 条评论

本文永久链接 – https://tonybai.com/2022/01/16/the-2021-review-of-go-programming-language

由于日常忙工作，闲时忙专栏，我早已策划的2021年Go语言盘点这篇文章一直拖到了2022年元旦之后才开始落笔。

2021年，Go迈过了其开源的第12个年头。虽然已经演进了10余年，但在编程语言这个领域中，Go依旧属于“小字辈”，仍处于快速的成长演化期。

纵观整个2021年，如果要用一句话来形容Go语言的发展，那就是厉兵秣马，蓄势待发。“厉兵秣马”这个成语的意思是把兵器磨快，把战马喂饱，形容做好战备，也比喻事前做好准备工作。那么2021年的Go究竟在为什么做准备呢？毫无疑问，它就是2022年泛型语法特性的落地。泛型既是Go社区最关注的语法特性，也是Go在语言特性方面的又一个“杀手锏”。

在“Go语言第一课”专栏的第一讲“前世今生：你不得不了解的Go的历史和现状”一文中，我曾提到过：绝大多数主流编程语言将在其诞生后的第15至第20年间大步前进。按照这个编程语言的一般规律，已经迈过开源第12个年头的Go很可能将进入自己的黄金5-10年。而2022年很大可能会成为Go语言黄金5-10年的起点，并且其标志只能是Go泛型语法的落地。

当然，Go核心团队以及Go社区所做的工作远不止打磨、优化和实现Go泛型语法这么简单，2021也是Go在其他方面成果丰硕的一年。下面我们就来盘点一下整个2021年Go语言的演化情况和当前状态，最后再对Go的2022年做个简单的展望。

我们先来看看2021年围绕Go语言项目以及Go社区都发生了哪些大事件(按时间先后顺序)！

一. 2021年Go大事件回顾

Go 1.16版本发布

按照一年发布两次大版本的节奏，Go核心团队于2021年2月18日发布了Go 1.16版本。该版本拥有一个重要的意义，那就是Go module构建模式成为了默认构建模式，这也意味着Go module构建模式的引入成功。与此同时，这一版本还支持了苹果的M1芯片（通过darwin/arm64环境变量组合）；新增io/fs包，建立Go原生文件系统抽象；新增embed包，作为在二进制文件中嵌入静态资源文件的官方方案；进一步对Go链接器进行现代化改造，新版链接器的性能相比于Go 1.15版本有20%-25%的提升，资源占用则下降5%-15%。编译出的二进制文件大小下降10%以上。

2020年Go用户调查结果发布

2021年3月初，Go官网发布了2020年Go用户调查结果。此次调查共收到近1w份有效调查反馈，报告的亮点如下：

Go在工作场所和企业中的使用范围不断扩大，76%的受访者在工作中使用Go，66%的人说Go对他们公司的成功至关重要。
总体满意度很高，92%的受访者对使用Go感到满意。
大多数受访者在不到3个月的时间里感觉到了Go的生产力，81%的受访者感觉Go的生产力非常高。
受访者表示会及时升级到最新的Go版本，76%的受访者在头5个月就升级了。
Go module得到了普遍的接纳与采用，满意度达到77%，但受访者也强调了对文档改进的需求。
Go继续被大量用于API、CLI、Web、DevOps和数据处理。

Go 1.17版本发布

2021年8月16日，Go 1.17版本在经过两个RC版本之后正式发布！Go 1.17版本并没有过多受到Go 1.18版本这个“网红”的影响，Go 1.17默默地加入和优化了着实不少的特性。其中最主要的三个变化是：

Go 1.17不再使用“完整module依赖图”，而是引入了pruned module graph（修剪的module依赖图）。修剪的module依赖图就是在完整module依赖图的基础上将那些“占着茅坑不拉屎”、对构建完全没有“贡献”的间接依赖module修剪后的依赖图。使用修剪后的module依赖图进行构建将有助于避免下载或阅读那些不必要的go.mod文件，这样Go命令可以不去获取那些不相关的依赖关系，从而在日常开发中节省时间。

在amd64架构实现了从基于堆栈的调用惯例到基于寄存器的调用惯例切换

切换到基于寄存器的调用惯例后，一组有代表性的Go包和程序的基准测试显示，Go程序的运行性能提高了约5%，二进制文件大小典型减少约2%。也就是说你的Go源码使用Go 1.17版本重新编译一下就能获得大约5%的性能提升。

Go开源12岁生日

2009年11月10日，Go语言正式对外发布并开源。2021年11月，距那一历史时刻已经过去12年了。Go核心团队技术负责人Russ Cox在Go官博撰文庆祝Go开源12周年。他简单回顾了这一年来Go核心团队与Go社区为Go的发展做出的卓越贡献，展望了在接下来的Go开源的第13个年头中，Go核心团队的工作重点，包括Go module的持续演进、Go泛型的落地、软件材料清单、Go漏洞数据库等。

Go官网切换

在2021年11月末，Go核心团队正式将Go语言官网从golang.org切换到go.dev。Go团队对官网体验的改善工作已经进行了很长时间了，从2019年go.dev被启用，到将godoc.org切换到pkg.go.dev，再到其他原官网功能逐一切换到go.dev上，Go核心团队在一点点的引导Gopher去使用和适应go.dev这个站点。

为了Go社区建设与Go官网改进，Go团队雇佣专人进行对应。Go核心开发团队专职人员的数量逐年增多。根据Go核心团队工程总监SAMEER AJMANI在之前Go Time的AMA环节中透露的信息，当前Go核心团队的规模已经达到了50余人：

不得不感慨一下：有一个有钱的爹是真好啊!

GopherCon 2021和Go 1.18Beta1发布

由于新冠疫情的影响，这两年的GopherCon大会都以网络直播的形式进行。今年的大会改在了12月初。GopherCon大会向来是既是Go社区的风向标，也是Go核心团队与Go社区互动的一个重要平台。在这次大会上，Go核心团队的两位重量级人物Robert Griesemer和Ian Lance Taylor亲自站台为大家讲解即将到来的Go泛型的相关内容与使用建议。

在GopherCon 2021大会余温未尽的时候，Go核心团队在美国时间12月14日宣布Go 1.18 Beta1发布。Go 1.18 Beta 1是第一个公测版，其主要功能变动包括Go泛型(类型参数)、Go工作区模式、支持Fuzzing test等。

Go团队这次少见的通过官博来发布一个beta版本，足以证明Go团队对Go 1.18版本的重视，毕竟Go 1.18是Go自诞生以来最大的一次语法变动，Go团队希望Go社区的gopher们广泛参与公测，在Go 1.18版本发布之前尽可能多地找出版本中存在的bug。

二. Go当前状态

经过一年多的发展与演化，Go语言当前的状态究竟如何呢？我们通过几个角度来看一下。

TIOBE排名上升一位

著名编程语言排名指数TIOBE近期发布了2021年各大主流编程语言最终排名：

从上图可以看到，在2021年，Go从2020年终的第14名上升到第13名，继续保持稳健的发展节奏。并且TIOBE配文中认为，除了Swift和Go之外，尚不会有新的编程语言能迅速进入前3名甚至前5名。这样说明了对Go趋势的看好。

在另外一份基于stackoverflow数据的编程语言排行榜redmonk上(仅2021上半年数据，下半年数据尚未发布)，Go保持稳定：

职业教育市场对Go的“追捧”可见一斑，Go“钱途”看好

职业教育市场直接反映了就业市场的需求。今年，国内头部的职业教育，比如：极客时间、慕课网都在Go语言这块发力。慕课网有谢大(astaxie)策划，曹春晖(xargin)主讲的Go高级工程师实战营。

极客时间更是上新多门Go语言相关专栏与课程，当然也包含笔者的“Go语言第一课”。在笔者与极客时间郭蕾总编的沟通中，郭总透露了极客时间对Go语言的几个判断：

就目前我们的观察来看，Go语言正在加速向企业渗透，越来越多的企业开始用Go。
就目前我们的观察来看，越来越多的开发者考虑将Go语言作为第二门编程语言。
云原生已经成为趋势，而Go语言是其主要采用的语言。
腾讯、字节跳动、美团、阿里、快手等头部公司正在大力推广Go。

Go在国内的就业市场的情况也是越来越好，在年底的一份程序员薪资报告中，我们看到国内Go程序员的平均薪资排在榜首：

这总体上也能反映出Go在国内就业市场的“钱途”还是不错的。

大厂Go新闻/输出盘点

Gopher们或想学习Go的童鞋都十分关注大厂中Go语言的应用情况。不过大厂中编程语言的应用范围只能通过官方或其雇员在一些渠道发布的消息来确认。下面是2021年大厂Go新闻/输出开源产品的盘点，通过这些内容我们可以大致勾勒出Go在大厂的应用情况。

腾讯

2021年初，腾讯官方发布《腾讯研发大数据报告》，在这份报告中，Go语言成为腾讯公司内部增速最快的语言：

2021年腾讯对外输出的公共资料以及开源的Go项目也充分印证了这一点：

可以说腾讯近些年在Go上面的投入很大，产出也颇丰。

字节跳动

字节跳动是国内大厂中拥抱Go的最积极的公司之一。从字节跳动的公开资料来看：

字节跳动的技术体系以Go语言为主。根据最新的调查统计，公司里有超过55％的服务是采用Go的，排名第二的语言是前端的NodeJS，之后是Python、JAVA、C++，Rust也有一些使用。

长期的Go实践让字节跳动内部积累的丰富的Go产品和经验，2021年字节也开启了对外开源之路，并且一次性放出若干基于Go的微服务框架与中间件产品，包括kitex、netpoll、thriftgo等。这些开源项目统一放在https://github.com/cloudwego下面了。

腾讯和字节是拥抱Go的急先锋，其他大厂、独角兽也有一些Go应用的动作，比如：微软发布了Go语言简明教程、其开源的dapr也有持续的演化，并招聘高级工程师参与Go官方编译器、工具生态开发；阿里的sealer；七牛云发布的Go+等。

国外的uber也是公开数据中使用Go打造服务最多的巨头公司，2021年uber也在其工程博客网站发布了一系列Go实践经验的深度文章，值得大家认真拜读和揣摩。

除了上面大厂积极拥抱Go之外，小公司与初创公司也在积极探索Go的落地。只不过小公司数据不好采集，从圈子里、周边朋友、面试时了解的情况，用Go的小公司/初创公司越来越多了。究其原因还是那句话：Go语言是生产力与性能的最佳结合。这对小公司/初创公司而言就是真(省)金(人)白(省)银(机器)啊。甚至Go已经渗透到新冠防疫领域，昨天得知河北移动支撑的流调系统的后端服务就是Go实现的。

接下来，我们再来展望一下2022年Go的发展情况会怎样。

三. Go语言2022展望

2022年，Go语言的最大事件就是2月份Go 1.18的发布以及Go泛型的伴随落地。泛型的加入势必会给Go社区带来巨大影响。随之而来的将是位于各个层次的Go包的重写或重构：底层库、中间件、数据结构/算法库、乃至业务层面。这一轮之后，Go社区将诞生有关于Go泛型编码的最佳实践，这些实践也会反过来为Go核心团队提供Go泛型演化与在标准库中应用的素材。

但泛型在提升语言表现力的同时，也会带来Gopher们最不想看到的复杂性，也正因为如此，Go核心团队也一直在努力向社区传达“Go泛型使用的一般准则”，以告知大家哪种场景适合使用泛型来加强代码，哪些场合泛型是不合适的。尽力防止泛型语法被滥用。

当然前面也说过，Go 1.18不仅仅是加入泛型，还有Go工作区模式以及原生支持fuzzing，前者是解决本地module开发与引用的方案，后者则为编写漏洞更少的代码提供了帮助。

有泛型加持的Go语言，“吸粉能力”得到了加强，将进一步得到来自其他语言阵营程序员的青睐。相信在2022年后半段，Gopher数量以及Go语言的受关注度都会有一定的增长。

Go泛型即将上路，也刚刚上路，离“完善”这个目标还有一定距离，就像go module一样，预计经过3-5个版本的打磨与优化，Go泛型才会真正成熟起来，并成为Go语言的又一柄利器。

综上，2021年，Go厉兵秣马，强化自身；2022，伴随着泛型的东风，Go语言将开启自己的新征程。

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

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

微信赞赏：
img{512x368}

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

Go 1.18新特性前瞻：Go工作区模式

十一月 12, 2021
5 条评论

本文永久链接 – https://tonybai.com/2021/11/12/go-workspace-mode-in-go-1-18

Go 1.18版本如无意外，将于2022年2月发布。

在这个版本中，除了包含万众期待的Go泛型之外，还包含很多实用的功能特性，Go工作区模式(Go workspace mode)就是其中之一，它弥补了当前go module构建模式的一些不足，堪称是go module构建模式的最后一块拼图。这篇文章我们就来看看什么是Go工作区模式，它究竟能解决什么问题。

一. 引子

1. replace带来的烦恼

近期在研究raft算法，参考的是etcd的raft实现。etcd还提供了一个raftexample的样例来说明如何实现基于raft的分布式应用。

要学习raftexample，我们首先要对其进行构建。raftexample的README.md文件中有raftexample编译方法的步骤，但这份安装步骤还停留在Go 1.11版本之前的gopath构建模式时期。如今我们要构建它，最好将其先转换为一个go module后再在go module模式下进行构建。不知道如何将一个legecy go project转换为go module的朋友可以去看一下我的极客时间专栏《Go语言第一课》^_^。

我们先把raftexample单独copy出来，放到一个单独的目录下，然后进入raftexample目录并在该其下执行下面命令添加go.mod文件，这里我们构建使用的go版本是go 1.17：

$cd raftexample
$go mod init github.com/bigwhite/raftexample

生成的go.mod内容如下：

$cat go.mod
module github.com/bigwhite/raftexample

go 1.17

接下来，我们执行go mod tidy命令让go命令自行分析raftexample的依赖并下载这些依赖：

$go mod tidy
go: finding module for package go.etcd.io/etcd/client/pkg/v3/types
go: finding module for package go.etcd.io/etcd/raft/v3/raftpb
go: finding module for package go.etcd.io/etcd/client/pkg/v3/fileutil
go: finding module for package go.etcd.io/etcd/server/v3/storage/wal
go: finding module for package go.etcd.io/etcd/server/v3/etcdserver/api/v2stats
go: finding module for package go.etcd.io/etcd/server/v3/etcdserver/api/snap
go: finding module for package go.etcd.io/etcd/server/v3/etcdserver/api/rafthttp
go: finding module for package go.etcd.io/etcd/raft/v3
... ...
go: downloading go.etcd.io/etcd/pkg/v3 v3.5.1
go: downloading go.etcd.io/etcd/api/v3 v3.5.1
go: finding module for package go.etcd.io/etcd/server/v3/storage/wal/walpb
go: finding module for package go.etcd.io/etcd/server/v3/storage/wal
github.com/bigwhite/raftexample imports
    go.etcd.io/etcd/server/v3/storage/wal: module go.etcd.io/etcd/server/v3@latest found (v3.5.1), but does not contain package go.etcd.io/etcd/server/v3/storage/wal
github.com/bigwhite/raftexample imports
    go.etcd.io/etcd/server/v3/storage/wal/walpb: module go.etcd.io/etcd/server/v3@latest found (v3.5.1), but does not contain package go.etcd.io/etcd/server/v3/storage/wal/walpb

go mod tidy命令报错，提示没找到server/v3.5.1下面的go.etcd.io/etcd/server/v3/storage/wal和go.etcd.io/etcd/server/v3/storage/wal/walpb包。翻看etcd工程server/v3.5.1标签下的源码，server下的确不包含storage这个目录。但在main分支下，storage目录是存在的。这很可能是etcd项目自v3.5.0版本开始进行多module改造(原先etcd项目是一个module，后该项目下拆分为多个module，并使用多module标签来管理)后的bug。

怎么处理这一情况呢？我们只能祭出replace大法了！刚说过etcd的main分支下storage目录是存在的，于是我们就手工修改一下raftexample的go.mod文件，添加下面这一行配置：

replace go.etcd.io/etcd/server/v3 v3.5.1 => /Users/tonybai/go/src/github.com/etcd-io/etcd/server

然后我们再执行go mod tidy，这回依赖分析与下载顺利完成了并且通过go build命令我们可以成功构建raftexample了。此时，raftexample的go.mod变成了这个样子：

module github.com/bigwhite/raftexample

go 1.17

replace go.etcd.io/etcd/server/v3 v3.5.1 => /Users/tonybai/go/src/github.com/etcd-io/etcd/server

require (
    go.etcd.io/etcd/client/pkg/v3 v3.5.1
    go.etcd.io/etcd/raft/v3 v3.5.1
    go.etcd.io/etcd/server/v3 v3.5.1
    go.uber.org/zap v1.19.1
)

require (
    github.com/beorn7/perks v1.0.1 // indirect
    github.com/cespare/xxhash/v2 v2.1.1 // indirect
    github.com/coreos/go-semver v0.3.0 // indirect
    github.com/dustin/go-humanize v1.0.0 // indirect
    github.com/gogo/protobuf v1.3.2 // indirect
    github.com/golang/protobuf v1.5.2 // indirect
    github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect
    github.com/prometheus/client_golang v1.11.0 // indirect
    github.com/prometheus/client_model v0.2.0 // indirect
    github.com/prometheus/common v0.26.0 // indirect
    github.com/prometheus/procfs v0.6.0 // indirect
    github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 // indirect
    go.etcd.io/etcd/api/v3 v3.5.0 // indirect
    go.etcd.io/etcd/pkg/v3 v3.5.0 // indirect
    go.uber.org/atomic v1.7.0 // indirect
    go.uber.org/multierr v1.7.0 // indirect
    golang.org/x/sys v0.0.0-20210603081109-ebe580a85c40 // indirect
    golang.org/x/time v0.0.0-20210220033141-f8bda1e9f3ba // indirect
    google.golang.org/protobuf v1.26.0 // indirect
)

但问题来了！require指示符将go.etcd.io/etcd/server/v3 v3.5.1替换为一个本地路径etcd源码拷贝下的server module，这个本地路径是因开发者环境而异的，但go.mod文件通常是上传到代码服务器上，这就意味着另外一个开发人员下载了这份代码后极大可能是无法成功编译的，他要想完成raftexample的编译，就得将replace后面的本地路径改为适配自己环境下的路径。于是乎每当开发人员pull代码后，第一件事就是要修改go.mod中的replace，每次上传代码前，可能也要将replace路径复原，这是一个很糟心的事情，但在Go 1.18版本之前似乎只能这样做。

2. 依赖本地尚未发布的module更糟糕

别急着学习Go工作区模式！我们再来看另外一个当前go module机制的问题。这个问题同样也是一位学员在我的《Go语言第一课》中咨询过的一个问题，我在《Go语言第一课FAQ》中曾对这个问题做个解答。在这里我再详细举例说明一下。

假设我有一个名为hello-module的项目，它的结构和代码都很简单：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/local-module/hello-module
$cat go.mod
module github.com/bigwhite/hello-module

go 1.17

$cat main.go

package main

import "github.com/bigwhite/a"

func main() {
    a.A()
}

我们看到：hello-module对外唯一的依赖是module path为github.com/bigwhite/a的module，但后者是一个尚在本地进行开发，还未发布到github.com上的module。如果此时执行go mod tidy，我们将得到下面错误提示：

$go mod tidy
go: finding module for package github.com/bigwhite/a
github.com/bigwhite/hello-module imports
    github.com/bigwhite/a: cannot find module providing package github.com/bigwhite/a: module github.com/bigwhite/a: reading https://goproxy.io/github.com/bigwhite/a/@v/list: 404 Not Found
    server response:
    not found: github.com/bigwhite/a@latest: terminal prompts disabled
    Confirm the import path was entered correctly.
    If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.

go命令无法找到github.com/bigwhite/a这个module。怎么办呢？我们目前的一个“土办法”就是自己“伪造”一个require，然后用replace将伪造的require指向本地的module a的目录。

下面是伪造的go.mod文件的内容：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/local-module/hello-module
module github.com/bigwhite/hello-module

go 1.17

require github.com/bigwhite/a v1.0.0

replace github.com/bigwhite/a v1.0.0 => /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.18-examples/foresight/workspace/local-module/module-a

通过go.mod内容可以看到，我们伪造了hello-module对github.com/bigwhite/a的v1.0.0版本的依赖，并用replace指示符将该版本指向本地的module-a的开发目录。

虽然“伪造”go.mod文件内容可以解决这个场景中的问题，但显然这种方法给开发者的体验也很差，这样的hello-module的go.mod文件一旦提交到代码仓库，同样会给其他开发者带去心智负担。

目前的Go module机制在解决上述两个场景时力不从心，显然缺少最后的那块拼图。而Go 1.18中将引入的Go工作区模式就是go module的最后那块拼图。下面我们就来简要看看Go工作区模式。

二. Go工作区模式

Go工作区模式是Go开发者Michael Matloob在2021年4月提出的一个名为“Multi-Module Workspaces in cmd/go”的proposal。这个proposal引入一个go.work文件用于开启Go工作区模式。go.work通过directory指示符设置一些本地路径，这些路径下的go module构成一个工作区(workspace)，Go命令可以操作这些路径下的go module，也会优先使用工作区中的go module。

我们先用go工作区模式解决一下前面提到的第一个问题。

在go 1.18版本发布之前，你需要使用gotip才能体验go工作区模式，安装gotip的方法如下：

$go install golang.org/dl/gotip@latest // go 1.17版本及以后使用go install。go 1.16及之前的版本用go get
$gotip download
$gotip version
go version devel go1.18-b7529c3 Tue Nov 9 06:27:04 2021 +0000 darwin/amd64

现在我们进入raftexample下面，然后通过下面命令初始化一个go.work:

$gotip work init .
$cat go.work
go 1.18

directory ./.

我们看到gotip work init命令创建了一个go.work文件，init后的路径被放在了go.work的directory指示符代码块中，directory指示符中的这些路径共同构成了一个Go工作区。我们将当前目录放入directory中，当前目录下的module就被置于我们的工作区当中了。

go.work还支持replace指示符，我们将前面放置在go.mod中的replace挪到go.work中：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/raftexample-with-go-workspace/go.work

go 1.18

directory ./.

replace go.etcd.io/etcd/server/v3 v3.5.1 => /Users/tonybai/go/src/github.com/etcd-io/etcd/server

然后我们再执行构建：

$gotip build

这回顺利通过了构建。将replace挪到go.work后，go.mod文件就可以放心地提交到远程代码仓库了，其他开发人员下载后也无需修改go.mod，因为他们也有自己的Go工作区模式go.work文件。

go.work配置的是开发者的本地工作区，因此是不建议提交到远程代码仓库中的，我们可以通过.gitignore将其忽略掉。我们甚至可以在任何go module的项目目录之外下放置go.work文件。

除了用replace，我们还可以将本地的etcd项目拷贝也纳入到我们的工作区当中，这样就无需replace了，比如我们可以将上面的go.work改为如下这样：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/raftexample-with-go-workspace/go.work

$cat go.work
go 1.18

directory (
    ./.
    /Users/tonybai/go/src/github.com/etcd-io/etcd
)

这样raftexample同样可以成功编译。

同样我们也可以通过这种方法解决我们在引子中提到的第二个问题。

和上面例子一样，我们为hello-module这个项目添加一个go.work：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/local-module/hello-module
$gotip work init ./ ../module-a
$cat go.work
go 1.18

directory (
    ./
    ../module-a
)

在这次init中，我们为init传入了两个路径，除了当前路径外，还将hello-module依赖的module-a在本地的路径传给了init，这样当前目录下的module与上层的module-a下的module就在同一个工作区当中了。接下来我们直接执行构建，go命令就可以在工作区顺利找到hello-module的依赖module-a了。

$gotip build
$./hello-module
this is a.A

三. 管理多module的工作区

最初这个proposal的名字就是multi modules workspace，即多module的工作区管理。当你的本地有很多module，且这些module存在相互依赖，那么我们可以在这些module的外面建立一个Go工作区，基于这个Go工作区开发与调试这些module就变得十分方便。

比如我们有三个module：a、b和c，其中a与b都依赖c。我们可以在a、b、c三个module路径的上一层创建一个Go工作区：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/multi-modules
$go work init a b c
$cat go.work
go 1.18

directory (
    ./a
    ./b
    ./c
)

这之后，三个module:a、b和c就都在刚刚创建的这个go工作空间了，我们基于该工作空间便可以构建a与b，以构建a为例：

// https://github.com/bigwhite/experiments/tree/master/go1.18-examples/foresight/workspace/multi-modules
$gotip build -o a_bin github.com/bigwhite/a
$./a_bin
C in c

四. 小结

Go 1.18尚未发布，Go工作区还在active开发中，很多机制可能在后续的几个月还会发生变化。上面的内容仅仅是对Go工作空间做一个前瞻性的介绍，Go 1.18正式发布后，Go工作空间的机制和使用可能与目前有一定差别。

另外，go mod tidy目前并不care Go工作区，这块在原proposal有提到，大家注意！

go workspace特性的作者在油管曾发过一个go工作空间的demo视频：https://www.youtube.com/watch?v=wQglU5aB5NQ&feature=youtu.be，demo是基于最初的go工作区实现做的，大家也可以去看看。

本文所涉及的源码在这里下载：https://github.com/bigwhite/experiments/tree/master/go1.18-examples。