包源之间的循环依赖

Question

假设您有一个mypack包含两个源文件mypack/a.go和mypack/b.go. 这两个源文件相互依赖，但 Go 编译器不会报错。如果你将该包分成两个，apack/a.go和bpack/b.go，Go 编译器会说import cycle not allowed。

我对如何处理包依赖关系的理解是，编译器将构建一个导入图。对图表进行了分析，并以某种方式（我很想了解执行此操作的算法！）计算了编译顺序。如果图中有环，则无法计算顺序，因此编译器会报错。

我不明白的是 Go 编译器如何能够解决包源之间的依赖关系但无法解决包之间的依赖关系。如果这两个来源相互依赖，那么你必须做一些疯狂的杂技并以某种方式同时编译它们。

有人可以帮我解决这个问题吗？

Answer 1

[...] Go 编译器如何能够解决包源之间的依赖关系但无法解决包之间的依赖关系。如果这两个来源相互依赖，那么你必须做一些疯狂的杂技并以某种方式同时编译它们。这个问题是基于对 Go 代码的结构和编译方式的错误假设：源文件没有 定义的依赖关系。包具有依赖性（所有从其所有源文件导入）。依赖项是包（不是源文件）。要编译一个包，所有依赖项都必须在编译开始之前可用。您真的必须停止考虑源文件。源文件（几乎）对 Go 代码的编译方式没有任何意义。一个包的源可能由一个或多个源文件组成，这基本上是源文件进入编译 Go 代码的唯一点。一切相关的事情都围绕着包和包：你编译包，你导入包，等等。（只是为了完整性：构建标签在源代码级别工作，包初始化可以依赖于源代码组织，通过手动调用 gc 你可以做的比通过 go 工具做的更多。）

Answer 2

无论使用多少源文件，一个包都被编译为一个单元。这真的不应该那么神秘。此外，您关于“如果存在循环则无法计算订单”的断言是完全错误的。计算这些东西是微不足道的——许多语言都这样做。不过，作为政策问题，Go 禁止这样做，因为它会导致代码的紧密耦合和难以理解的代码，而不是因为它是不可能的。