我可以在多个源目录中开发一个 go 包吗？答案

【问题标题】：Can I develop a go package in multiple source directories?我可以在多个源目录中开发一个 go 包吗？
【发布时间】：2018-02-04 13:19:03
【问题描述】：

我正在开发一个go包，它有点复杂，因此我想将源代码组织到多个目录中。

但是，我不希望包的用户必须使用太长的导入。无论如何，包的内部结构不是他们关心的。

因此，我的包结构如下所示：

subDir1
  subSubDir1
  subSubDir2
subDir2
  subSubDir3

...等等。他们都有自己的导出调用。

我想避免我的用户必须导入

import (
  "mypackage/subDir1"
  "mypackage/subDir1/subSubDir2"
)

...等等。

我只想，如果他们想使用我的包中的导出函数，他们应该可以通过简单地导入 mypackage 来访问所有这些函数。

我尝试在所有.go 文件中声明package mypackage。因此，我的源文件位于不同的目录中，但具有相同的包声明。

在这种情况下，我遇到的问题是我根本无法从同一个包中导入多个目录。它说：

./src1.go:6:15: error: redefinition of ‘mypackage’
   "mypackage/mysubdir1"
               ^
./src1.go:4:10: note: previous definition of ‘mypackage’ was here
   "mypackage"
          ^
./src1.go:5:15: error: redefinition of ‘mypackage’
   "mypackage/mysubdir2"
               ^
./src1.go:4:10: note: previous definition of ‘mypackage’ was here
   "mypackage"
          ^

有没有可能？

【问题讨论】：

标签： go

【解决方案1】：

在任何情况下都不应这样做，因为语言规范允许编译器实现拒绝此类构造。引用自Spec: Package clause:

一组文件共享相同的 PackageName 形成一个包的实现。 实现可能要求包的所有源文件位于同一目录中。

改为“构建”文件名以模仿文件夹结构；例如而不是文件

foo/foo1.go
foo/bar/bar1.go
foo/bar/bar2.go

你可以简单地使用：

foo/foo1.go
foo/bar-bar1.go
foo/bar-bar2.go

另外，如果你的包太大以至于你需要多个文件夹来“托管”包实现的文件，你真的应该考虑不要将它作为一个包来实现，而是将它分成多个包。

还要注意Go 1.5 引入了internal packages。如果您在包文件夹中创建一个特殊的internal 子文件夹，您可以在其中创建任意数量的子包（即使使用多个级别）。您的包将能够导入和使用它们（或者更准确地说，所有包都植根于您的包文件夹），但外部没有其他人能够这样做，这将是一个编译时错误。

例如你可以创建一个foo 包，有一个foo/foo.go 文件和foo/internal/bar 包。 foo 将能够导入 foo/internal/bar，但例如boo 不会。此外，foo/baz 也可以导入和使用foo/internal/bar，因为它植根于foo/。

因此，您可以使用内部包将大包分解为较小的包，从而有效地将源文件分组到多个文件夹中。您唯一需要注意的是将您的包想要导出的所有内容放入包中，而不是放入内部包中（因为那些不能从“外部”导入/可见）。

【讨论】：

我喜欢这个答案，但我真的很想讨厌它。来自 java 世界，很难不本能地想要将您的源逻辑划分为多个文件夹。 :D
@ArloGuthrie 但是您可以将源分成多个文件夹，这是标准的，它们只是不能属于同一个包的一部分。您也有 Java 包，位于不同的文件夹中。
java.util 是一个包。在它下面是任意数量的“文件夹”......集合等。我是一个严肃的 golang 新手，但似乎如果你想编写一个 API，你真的需要将所有内容都放入一个文件夹中，以便用户只需要导入一个包，否则会出现循环依赖问题。我对 golang 包结构的理解有误吗？
@ArloGuthrie 是的，包的文件必须位于单个文件夹中是正确的。但您不仅限于使用单个包。例如。标准库有一个image 包和其他几个用于图像类型的包（例如image/jpeg），以及不同包中的一些部分，例如image/color、image/draw 等。有一些技术可以解决循环依赖关系，请参阅 Registering packages in Go without cyclic dependency。还有上面提到的内部包。
我没有看到 Go 的包系统无法解决的限制。它们只是不是一对一地等同于 Java 的包。这是一种不同的语言，具有不同的规则和原则。用 Go 开发不是用 Java 开发。

【解决方案2】：

是的，这是可行的，没有任何问题，只需手动调用 Go 编译器，而不是通过 go 工具。

但最好的建议是：不要那样做。这是丑陋的，不必要的复杂。只需正确设计您的包装即可。

【讨论】：

【解决方案3】：

在您的包源代码中，您必须通过重命名导入来区分您的源目录。您可以在所有源文件中声明相同的package mypackage（即使它们位于不同的目录中）。

但是，当您导入它们时，您应该为目录指定一个单独的名称。在你的源src1.go中，以这种方式导入其他目录：

import (
  "mypackage"
  submodule1 "mypackage/mySubDir"
)

您将能够访问“mypackage”中定义为mypackage.AnyThing() 的API，以及mySubDir 中定义为submodule1.AnyThing() 的API。

外部世界（即您的包的用户）将在myPackage.AnyThing() 中看到所有导出的实体。

避免命名空间冲突。并像示例中那样使用更好的、更不稳定、更直观的命名。

【讨论】：