本文永久链接 – https://tonybai.com/2023/04/08/the-reason-why-go-test-fails-when-module-path-is-main

近期收到新加入“Gopher部落”知识星球的星友“凌风”的一个问题，内容如下：

在一个目录下，我编写了a.go和a_test.go，在go mod init main后执行go test，会报错：could not import main( can not import "main")。我知道它的解决方法是改变包名。我的问题是：
1. 难道无法对 main 包执行包内测试了么。
2. 这里的报错的底层原因是什么。

本文将针对这个问题做一个简要的分析，这将涉及到go module、go package和package import的相关概念以及go test的工作原理等内容。

1. 建立试验环境，复现问题

我们先搭建一个试验环境，复现一下这位星友遇到的问题：

// https://github.com/bigwhite/experiments/blob/master/module-path-main
$tree module-path-main
module-path-main
├── go.mod
├── pkg.go
└── pkg_test.go

$cat go.mod
module main

go 1.20

$cat pkg.go
package main

func Add(a, b int) int {
    return a + b
}

$cat pkg_test.go
package main

import (
    "testing"
)

func TestAdd(t *testing.T) {
    n := Add(5, 6)
    if n != 11 {
        t.Errorf("want 11, got %d\n", n)
    }
}

好了！我们执行go test运行测试：

$go test
# main.test
/var/folders/cz/sbj5kg2d3m3c6j650z0qfm800000gn/T/go-build1902276879/b001/_testmain.go:14:8: could not import main (cannot import "main")
FAIL    main [build failed]

我们看到：这里使用Go 1.20版本执行的go test命令报错！报错内容与星友的问题一致！问题复现了！接下来我们就来分析一下为何会报错！

2. go module、go package与import path

分析问题之前，我们还是要理清楚go module、go package与import path这几个概念。

go package的概念大家已经很熟悉了，这是Go的基本编译单元，是go从娘胎里就带的概念。后面的go module、import path与package概念都相关。

Go在1.11版本引入go module，之后go module就替代gopath构建模式成为了Go标准构建模式。

Go mod参考手册中关于go module的定义是：“一个module由一个module path来识别，go.mod文件中声明了module path以及关于该module的依赖信息(require、replace等)。包含go.mod文件的目录被称为module root directory。main module是包含调用go命令的目录的module。

注：本文只讨论go module模式，过时的GOPATH模式不再讨论之列。
注：main module的说法极易造成概念混淆，在Go 1.21版本或后续版本中可能会改为work module。

Go module的引入是为了解决依赖管理问题，所以go module是一组package的集合，这组package的版本与module版本绑定。但go module的引入，也对package的import path的确定与含义产生了些许影响。

GOPATH构建模式时代，go package的导入路径(import path)是该package所在目录相对于\$GOPATH/src的路径来确定的。比如你的package放在了\$GOPATH/src/github.com/user/repo下，那么你的package的导入路径就是import “github.com/user/repo”。这和当时go get下载包的路径规则是一致的。

在Go module时代，\$GOPATH/src不再强制，go module与\$GOPATH/src也没有任何耦合关系了。这时，go package的导入路径由go module path和package在module中的相对路径共同确定：

• 如果你的module path(go.mod文件中声明)为github.com/user/yourmodule，你的package在yourmodule根路径下的foo/bar目录下，那么你的package的导入路径就是github.com/user/yourmodule/foo/bar。
• 如果你的module使用了自定义module路径，比如：example.com/go/yourmodule，那么同样，如果你的package在yourmodule根路径下的foo/bar目录下，这个package的导入路径将为example.com/go/yourmodule/foo/bar。
• 如果你的module采用的不是上述两种url的方式，而是使用tonybai/yourmodule这样的“本地路径”形式，那么如果你的package在yourmodule根路径下的foo/bar目录下，这个package的导入路径将为tonybai/yourmodule/foo/bar。

注：除了做包导入路径的前缀，module path还可以用来指示module存放的版本托管服务的url地址。

上面概念与它们的关系对解决我们文首处的问题有什么帮助呢？别急！下面这个推论与本文那个问题强相关。

3. module root directory的包的导入路径是什么

好了，下面就是与本文开头那个问题最相关的一个问题了：go module的根目录(module root directory)下的package的导入路径是啥？根据上面对go module模式下package导入路径的定义：go module根目录下包的导入路径就是module path。

以我们上面的试验项目为例，main module的根路径为module-path-main目录，该目录下面存放了一个包main(pkg.go)，那么该main包的导入路径就为go module的module path：”main”。即便你将pkg.go中的包名由”main”改为”demo”，demo包的包导入路径依旧为”main”。

注：《Go语言第一课》专栏04讲和06讲有关于包导入路径的深入理解。
注：星友凌风在问题中说：改变go包名可以解决这个问题，这个说法是不正确的。将上面的包名main改为demo，go test依然会报同样的错误。

4. go test的原理

好了！关于go module、package以及package import路径的概念复习的差不多了，这些概念的复习是解决文首问题的一个前提，我们先把它们暂存在大脑里。我们再聊看另一半知识：go test。

Go test是Go内置的测试框架，我们可以用它来驱动单元测试、集成测试甚至是自动化测试。

在一个包内执行go test后，go test会首先编译目标包，然后编译测试包(测试包和目标包可能是一个包，也可能是不同包)，即目录下所有以_test.go为后缀的源文件。go test会将测试包编译为一个可执行文件，这个可执行文件的main包会依赖并导入测试包，并会调用测试包中的TestXxx导出方法执行测试。

注：go test -c可以得到这个可执行文件pkg.test

5. 真相大白

好了，有了上述关于两个知识准备后，我们来揭开问题的真相！

我们使用go test -work来查看go test执行生成的可执行文件的main函数所在文件(传入-work标志的目的是让go编译器在编译后依然保留构建测试源文件的临时目录)：

// 在module-path-main下执行

$go test -work
WORK=/var/folders/cz/sbj5kg2d3m3c6j650z0qfm800000gn/T/go-build2039841248
# main.test
/var/folders/cz/sbj5kg2d3m3c6j650z0qfm800000gn/T/go-build2039841248/b001/_testmain.go:14:8: could not import main (cannot import "main")
FAIL    main [build failed]

打开临时路径下b001下面的_testmain.go，这个文件是go test工具生成的：

// Code generated by 'go test'. DO NOT EDIT.

package main

import (
    "os"

    "testing"
    "testing/internal/testdeps"

    _test "main"

)

var tests = []testing.InternalTest{

    {"TestAdd", _test.TestAdd},

}

var benchmarks = []testing.InternalBenchmark{

}

var fuzzTargets = []testing.InternalFuzzTarget{

}

var examples = []testing.InternalExample{

}

func init() {
    testdeps.ImportPath = "main"
}

func main() {

    m := testing.MainStart(testdeps.TestDeps{}, tests, benchmarks, fuzzTargets, examples)

    os.Exit(m.Run())

}

我们看到这就是我们要编译出来的测试可执行文件的main包和main函数的内容，其中最关键的一行是：

import (
    ... ...

    _test "main" // 这行是导致go test执行出错的“罪魁祸首”

    ... ...
)

根据我们之前复习的go module下package导入路径的定义，这里的”main”其实是module-path-main这个module根路径下的包的导入路径，前面说了：这个顶层包(无论包名是什么，是main也好，是demo也罢)的导入路径就是module path，而这里我们定义的module path是main，因此这里的路径为”main”。

根据包导入路径规则，如果是像”fmt”、”io”这样的导入路径，go编译器会从标准库中搜索；如果是”main”，则认为是main包。

好了，问题来了！这个_testmain.go是go test生成的测试可执行程序的main包，它现在又导入了一个”main”包，而Go语言是不允许导入main包的。因为main包以及main函数通常是用来集成你的各个代码单元（也就是包）的，如果你的其他代码单元再依赖main，就会造成“循环导入”，这在Go中是绝对禁止的。这就是文首问题的真正原因。

注：main包支持单元测试，但通常建议不要针对main包进行单元测试。如果你在main里有值得测试的代码（用于单元测试；而不是用于集成测试），可以考虑把它移到一个库包里。

知道了真因后，解决方法也十分简单，那就是重命名module path，比如改为demo，这样go test就会成功执行了。而改为demo后，_testmain中导入代码变成了：

import (
    ... ...

    _test "demo" 

    ... ...
)

这显然不会导致go编译器报错！

6. 参考资料

• go mod reference – https://go.dev/ref/mod
• “Tests in main package don’t work with GO111MODULE=on” – https://github.com/golang/go/issues/28514

本文涉及的代码可以在这里下载 – https://github.com/bigwhite/experiments/blob/master/module-path-main

“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/04/02/map-element-types-support-in-place-update

年初，我代表团队和人民邮电出版社签订了翻译《Go Fundamentals》一书的合同，本月底便是四分之一进度的交稿时间点，近期闲时我们都在忙着做交叉review。

上周末我review小伙伴翻译的有关map类型的章节时，看到了书中对map element就地更新的讲解。Mark Bates和Cory LaNou的这本书属于入门级Go语言书，只是举例说明了一些支持就地更新的map element类型以及不能就地更新的典型类型，但对不能更新的原因并未做深入说明。我觉得这个知识点不错，借这篇文章系统梳理一下。

一. 什么是map element的就地更新(in-place update)

我们知道Go中的map类型是一种无序的键值对集合，它的内部实现是基于哈希表的，支持高效地进行插入、查找和删除操作。map的key必须是可以进行相等比较的类型，比如整数、字符串、指针等，而element(也称为value)则可以是任意类型。并且，map是引用类型，它的零值为nil，使用前需要先使用内置函数make或map类型字面值进行空间分配。此外，在使用map时还需要注意并发安全问题，可以使用sync包提供的同步原语中来实现map的并发安全。

更多关于map的入门介绍与原理说明，可以阅读我的极客时间专栏《Go语言第一课》的第16讲。

下面我们就来声明一个简单的map类型变量：

m := map[string]int{}

m是一个键为string类型、element为int类型的map。我们可以通过下面代码向map中插入一个键值对：

m["boy"] = 0

我们可以将其想象为一个统计班里男孩子数量的计数器：每数到一个男孩，我们就可以将其加1：

n := m["boy"]
n++
m["boy"] = n

你可以看到上述代码更新了键”boy”对应的element值(+1)。不过这种方法比较繁琐，要更新键”boy”对应的element值，我们还有下面这个更为简洁的方法：

m["boy"]++

我们看到和前面一种方法相比，这种方法没有引入额外的变量(比如前面的变量n)，而是直接在map element上进行了更新的操作，这种方法就称为map element的“就地更新”。

下面还有一些支持“就地更新”的map element类型的例子，比如：string、切片等：

m["boy"] += 1

// element类型为string
m1 := map[int]string{
    1 : "hello",
    2 : "bye",
} // map[1:hello 2:bye]

m1[1] += ", world" // map[1:hello, world 2:bye]

// element类型为切片
m2 := map[string][]int{
    "k1": {1, 2},
    "k2": {3, 4},
} // map[k1:[1 2] k2:[3 4]]
m2["k1"][0] = 11 // map[k1:[11 2] k2:[3 4]]

不过并非所有类型都支持“就地更新”，比如下面的数组与结构体作为map element类型时就会导致编译错误：

m3 := map[int][10]int{
    1 : {1,2,3,4,5,6,7,8,9,10},
}
m3[1][0] = 11 // 编译错误：cannot assign to m3[1][0] (value of type int)

type P struct {
    a int
    b float64
}

m4 := map[int]P {
    1 : {1, 3.14},
    2 : {2, 6.28},
}
m4[1].a = 11 // 编译错误：cannot assign to struct field m4[1].a in map

注：Go issue 3117一直跟踪着上述结构体类型作为map element时不能就地更新的问题。该issue并没有close，说明也许未来Go针对这样的行为的处理可能会发生变化。

那么为什么会这样呢？为什么同样作为map element，有的类型可以就地更新，有的类型就不支持呢？我们继续向下看。

二. element类型支持就地更新的本质

实际上，这种支持element类型就地更新其实是一种“语法糖”，比如我们以上面的m变量为例：

m := map[string]int{
    "boy" : 0,
}

当我们执行下面的就地更新语句时：

m["boy"]++

上面的语句就等价于：

a := m["boy"]
a++
m["boy"] = a

我们再来看下面element为字符串类型的例子：

m1 := map[int]string{
    1 : "hello",
    2 : "bye",
} 

m[1] += "world"

上述字符串连接语句等价于：

s := m[1]
s += "world"
m[1] = s

到这里小伙伴们可能会问：为什么Go不针对类型为struct和array的element提供这种语法糖呢？我们假设struct的字段更新也支持就地更新，那么会发生什么呢？

type P struct {
    a int
    b float64
}

m4 := map[int]P {
    1 : {1, 3.14},
    2 : {2, 6.28},
}
m4[1].a = 11

上面的m4[1].a = 11将等价于如下代码：

t := &(m4[1])
t.a = 11

我们看到与element类型为int或string不同，由于要更新struct内部的字段，我们这次必须获取element的地址。一旦可以获取地址，问题就来了！这个地址是map在runtime层维护的内存地址，一旦暴露出来至少会有如下两个问题：

• 并发访问时会导致该element数据的竞争问题；
• map自动扩容后，element地址会变更，通过上述代码获取的地址可能变为无效。

当然第二点更为重要，也正是因为这个原因，Go决定不支持对map的element取地址。

到这里有些小伙伴可能会问：针对struct和array类型的element，为什么不提供下面这样的“语法糖”呢？以struct为例：

m4[1].a = 11 

<=>

t := m4[1]
t.a = 11
m4[1] = t

即将struct和array作为一个整体，从map中获取副本，然后在临时变量中更新后，再重新覆盖map中的element。

go为什么不提供这种“语法糖”呢？我猜是因为这么做的性能开销较大！struct可以聚合很多字段，array的size也可能很可观，这样的两次copy的开销可能是Go开发者比较顾忌的。

那么目前的替代方案是什么呢? 其实很简单，那就是element类型使用指针类型，比如下面element类型为结构体指针类型的代码：

type P struct {
    a int
    b float64
}

m := map[int]*P{
    1: {1, 3.14},
    2: {2, 6.28},
}
fmt.Println(m[1]) // &{1 3.14}

m[1].a = 11

fmt.Println(m[1]) // &{11 3.14}

再比如element类型为数组指针类型的代码：

m1 := map[int]*[10]int{
    1: {1, 2, 3},
}
fmt.Println(m1[1]) // &[1 2 3 0 0 0 0 0 0 0]
m1[1][0] = 11
fmt.Println(m1[1]) // &[11 2 3 0 0 0 0 0 0 0]

对map element“就地更新”的限制也会影响到是否能调用element类型的相关方法，我们再来看下面例子：

type P struct {
    a int
    b float64
}

func (P) normalFunc() {
}

func (p *P) updateInPlace(a int) {
    p.a = a
}

func main() {

    m1 := map[int]P{
        1: {1, 3.14},
        2: {2, 6.28},
    }
    m1[1].normalFunc()
    m1[1].updateInPlace(11) // 编译错误：cannot call pointer method updateInPlace on P

    m2 := map[int]*P{
        1: {1, 3.14},
        2: {2, 6.28},
    }
    fmt.Println(m2[1].a) // 1
    m2[1].normalFunc()
    m2[1].updateInPlace(11)
    fmt.Println(m2[1].a) // 11
}

我们看到当element类型为P时，我们无法通过语法糖来调用会对结构体字段进行修改的updateInPlace方法，但可以调用normalFunc。而当element类型为P指针类型时，则无此限制。

那么，我们究竟如何判断哪些类型支持就地更新，哪些不支持呢？我们接下来就来说说。

三. element类型是否支持就地更新的判断方法

我们先来梳理一下Go的主要类型是否支持就地更新。

• 不涉及就地更新的类型

当element类型为布尔类型、函数类型时，我没找出针对这些map element就地更新的写法。

注：函数在Go中是一等公民。

• Go原生的基本类型，比如整型、浮点型、complex类型、string类型等

当这些类型作为map element类型时，虽然它们保存在map数据结构管理的内存中，但根据前面的讲解，我们知道Go针对这些element type提供的“就地更新”语法实际上是一个语法糖，Go实际做的依然是整体替换：

// 整型
m1 := map[int]int{
    1: 1,
}
m1[1]++
fmt.Println(m1[1]) // 2

// 浮点型
m3 := map[int]float64{
    1: 3.14,
}
m3[1]++
fmt.Println(m3[1]) // 4.140000000000001

// complex类型
m4 := map[int]complex128{
    1: complex(2, 3), // 2+3i
}
m4[1]++
fmt.Println(m4[1]) // 3+3i

// string类型
m5 := map[int]string{
    1: "hello",
}
m5[1] += " world"
fmt.Println(m5[1]) // hello world

• 对于指针、map、channel等类型

通过前面的讲解，我们知道使用指针作为map element类型是支持就地更新的，这里就不重复举例了。

map类型自身在Go运行时表示中也是一个指针，它也是支持就地更新的：

m := map[int]map[int]string{
    1: {1: "hello"},
}
m[1][1] += " world"
fmt.Println(m[1][1]) // hello world

关于channel类型，如果将向channel写入数据当作“就地更新”的话，那么channel也勉强算是支持：

// channel
m1 := map[int]chan int{
    1: make(chan int),
}
go func() {
    m1[1] <- 11
}()

fmt.Println(<-m1[1]) // 11

• 对于切片、接口类型

通过前面的讲解，我们知道使用切片作为map element类型是支持就地更新的，这里就不重复举例了。

而对于接口类型，我理解的就地更新场景有两种，一种是通过接口值调用动态类型的方法，一种则是通过type assert来修改某些值。下面这两个场景的示例代码：

type MyInterface interface {
    normalFunc()
    updateInPlace(a int)
}

type P struct {
    a int
    b float64
}

func (P) normalFunc() {
}

func (p *P) updateInPlace(a int) {
    p.a = a
}

func main() {
    // interface
    m1 := map[int]MyInterface{
        1: &P{1, 3.14},
    }

    m1[1].updateInPlace(11) // 场景1：调用就地更新的方法

    p := m1[1].(*P)
    fmt.Println(p.a) // 11

    (m1[1].(*P)).a = 21     // 场景2：通过type assert设置值
    p = m1[1].(*P)
    fmt.Println(p.a) // 21
}

• 对于数组、struct类型

通过前面的讲解，我们知道使用数组和struct类型作为map element类型是不支持就地更新的，这里就不重复举例了。

通过对上面诸多类型的示例与理解，不知道你是否发现了支持“就地更新”的map element类型的一些共同特点。

除了语法糖之外（比如int、string、float64等），其余支持“就地更新”的map element类型(比如指针、切片、接口等)有一个共同的特点，那就是我们要就地更新的值对应的内存并不在map的管辖范围内。

以切片为例，如下图：

我们知道切片在运行时的表示为包含三个字段的结构体，因此map[int][]int实际上是一个map[int]SliceHeader。而这个map的element的就地修改：m[1][0] = 11实际上并未修改SliceHeader中的任何值，修改的是SliceHeader中data指针指向的切片底层数组的元素。

更多关于切片的基础知识与运行时表示原理，可以阅读极客专栏《Go语言第一课》的第15讲。

这就是为什么切片类型的map element支持就地修改的原因。由此来看指针、接口等类型，都是同样的道理，即element自身值并未有被修改，而是element指向的map结构之外的内存区域被修改了！

一句话：只要修改的位置不在map管辖的内存中，那这个map element类型就支持就地更新。

“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

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