我们正在将我们的内部代码库从dep依赖管理器转换为 go 模块（vgo或内置于 go1.11.2）。想象一下我们有这样的代码：
$GOPATH/src/mycompany/myprogram/main.go：
package main
import (
"fmt"
lib "mycompany/mylib" )
func main() {
fmt.Println("2+3=", lib.add(2, 3))
}
$GOPATH/src/mycompany/myprogram/go.mod：
module mycompany/myprogram
（它没有任何依赖关系；我们的实际代码有）。
$GOPATH/src/mycompany/mylib/lib.go：
package mylib
func Add(x int, y int) int {
return x + y
}
我没有对这段代码进行模块化；我做或不做似乎并不重要。
这些都是微不足道的例子，但我们的内部代码遵循与历史上类似的结构。
由于这些目录在 Gopath 上，export GO111MODULE=auto仍然像以前一样构建，并且工作正常（因为我们在 gopath 上而没有使用模块）。但是，当我设置时，export GO111MODULE=on我立即收到错误：
build mycompany/myprogram: cannot find module for path mycompany/mylib
所以我做了一些研究，我想验证我的理解。首先让我说我们的旧方法有效，但我更感兴趣的是更改为使用 go 模块，因为它似乎是 go 项目本身的发展方向。所以。
似乎 golang 作者的意图是“无点”路径仅属于标准存储库；那就是域名和项目之间应该有绑定。不出所料，我们不使用 go get 进行内部项目。这里是具体的来源：
通常为标准库保留无点路径；go get （据我所知）从未使用过它们，但 go get 也是使用版本化模块的主要入口点。
比我更了解 golang 的人可以证实这一点吗？
我的关键假设是，一旦 go 决定使用模块，所有依赖项都必须是模块，并且 gopath 变得有些无关紧要，除了作为缓存（用于下载的模块）。这个对吗？
如果这是真的，我们需要在路径上使用私有 gitlab（在我们的例子中）存储库。我知道在处理这个问题上有一个未解决的问题，因此我们可以在必要时实施。我对后果更感兴趣，特别是在私有存储库中进行迭代。以前我们可以在提交任何更改之前在本地开发这些库；现在看来我们有一个选择：
- 接受这个远程依赖并迭代。我希望避免像这样远程推拉。如果绝对必要，有需要互联网连接的解决方法。
- 将所有内容合并到一个大的 git 存储库中。
如果重要的话，我正在使用go version go1.11.2 linux/amd64，我的同事正在使用darwin/amd64. 如果有帮助，我的 golang 与 Fedora 存储库中安装的完全一样。
所以，tl;dr我的问题是：go 模块是全有还是全无，因为任何依赖都必须使用模块系统（似乎是 go get）来解决，并且 gopath 已经变得多余了？或者我的设置是否有可能导致此失败？有什么方法可以表明应该从 gopath 显式解决依赖关系？
自提出问题以来的更新：
- 我可以
myprogram离开gopath。发生同样的问题（mylib已留在 gopath 中）。 go mod init mycompany/mylib我可以在 mylib 目录中运行，也可以不运行；它根本没有区别。- 我在 vgo 上看到了 Russ Cox 的博文。我对离线开发的担忧，我尽量不深入研究，但通过
$GOPROXY.