在任何情况下都不应该这样做，因为语言规范允许编译器实现拒绝这样的构造。封装子句：
一组共享相同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/。
所以你可以使用内部包把你的大包分解成更小的包，有效地把你的源文件分组到多个文件夹中。你唯一需要注意的是把你的包想要导出的所有东西都放进包里，而不是放进内部包里（因为那些东西从“外部”是不可导入/不可见的）。

在你的包源代码中，你必须通过 renamed imports 来区分你的源目录。你可以在你的所有源文件中声明相同的package mypackage（即使它们在不同的目录中）。
但是，在导入它们时，您应该为这些目录给予一个单独的名称。在您的源src1.go中，按以下方式导入其他目录：

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

您将能够访问在“mypackage”中定义为mypackage.AnyThing()的API，以及在mySubDir中定义为submodule1.AnyThing()的API。
外部世界（即包的用户）将看到myPackage.AnyThing()中的所有导出实体。
避免命名空间冲突，并使用更好的欠稳定、直观的命名，如示例所示。

是的，这是可以做到的，没有任何问题，只需手动调用Go编译器，而不是通过go工具。
但最好的建议是：不要这样做。这很难看，而且不必要地复杂。只要正确地设计你的 Package 就行了。
补遗（因为这个回答的真实的意图有时似乎会迷失，也许是因为讽刺太微妙了）：不要这样做！！这是一个难以置信的愚蠢的想法！停止对抗工具！如果你这样做，每个人都会理所当然地恨你！没有人会理解你的代码或能够编译它！仅仅因为一些事情在理论上是可行的，并不意味着这是一个明智的想法在任何方面。甚至不是为了“学习的目的”！你甚至可能不。我不知道如何手动调用Go语言编译器，如果你弄清楚了，那将是一个很大的难题。