每当Go程序编译出现循环引入报错的时候就非常让人头疼。
那么，为什么Go不允许循环引入呢？
我觉得原因如下：
搞清楚package包的定位
首先，搞清楚Go语言中package包的定位；
Go语言的packa和其他语言中的库、模块是相同的概念，在其他语言中，实现某个库或者模块需要建立"单独的项目"，而在Go中，仅仅是一个包就够了。
在正常Coding的时候，在我们项目中可以随便引入外来的项目(例如PHP项目引入PHP包)，但是，我们可以随意的修改引入的包吗？不可以！在我们写PHP的时候，我们可以引外来的包，并在引入的包中做修改，和现有项目循环依赖吗？更不可以！
从这个角度来讲，Go语言不允许循环引入，算是合情合理的，因为Go中的package就是相当于其他语言中的“一个小项目”。
语言设计层面
第二，我们考虑一下，循环引入可能带来的坏处。
曾经有人提议Go语言作者Rob Pike，想要在Go以后的版本去掉循环引入；Rob Pike坚决不同意。Rob Pike觉得假如你两个包之间存在循环引入的问题，那一定是你在设计之初就没考虑好模块的划分。
我们试想，假如允许循环引入，那么，模块和模块之间就存在相互的调用，随着项目的推进，模块之间的依赖关系越来越多，最后导致俩模块耦合性变的很高，最初模块之间的界限变的越来越模糊，最后都偶合在一起了，变的一团糟。一个好的设计，一个好的模块的划分，就不应该存在循环依赖的问题！
因此，Go语言在设计之初，就强制要求不允许循环引入，这会迫使开发者在写代码之前就考虑模块与模块之间的依赖关系，保持依赖关系的整洁。否则，允许循环引入，虽然带来了coding的方便，但是从工程的长远角度来考虑，对整个工程的构建、代码的整洁都是非常不利的。
其他原因
最后一点，禁止循环引入会让编译变的更高效。
